4.7 Dienststartfehler analysieren

[ ] Datum, Uhrzeit und Zeitzone
[ ] Server und Betriebssystem
[ ] Interner Dienstname beziehungsweise launchd-Label
[ ] Aktueller Dienststatus
[ ] Startart beziehungsweise Aktivierungszustand
[ ] Prozess-ID, falls vorhanden
[ ] Letzter Exitcode
[ ] Dienstspezifischer Exitcode
[ ] Programmpfad und Startparameter
[ ] Dienstkonto
[ ] Formale Abhängigkeiten
[ ] Wiederherstellungs- und Neustartregeln
[ ] Relevante Systemprotokolle
[ ] Relevante Anwendungsprotokolle
[ ] Letzte Konfigurations- oder Softwareänderung

Erst nach dieser Sicherung sollte ein weiterer kontrollierter Startversuch durchgeführt werden.

Dienst vorhanden?
  ↓
Aktiviert und nicht blockiert?
  ↓
Programmpfad vorhanden?
  ↓
Startkonfiguration syntaktisch gültig?
  ↓
Dienstkonto gültig?
  ↓
Datei- und Verzeichnisrechte ausreichend?
  ↓
Abhängigkeiten verfügbar?
  ↓
Port und andere Ressourcen verfügbar?
  ↓
Prozess startet?
  ↓
Prozess bleibt aktiv?
  ↓
Dienst meldet Betriebsbereitschaft?
  ↓
Anwendungstest erfolgreich?

Empfohlene Reihenfolge:

1. Exakten Dienstnamen bestätigen.
2. Aktuellen Status erfassen.
3. Exitcode und Protokolle sichern.
4. Startart und Blockierungen prüfen.
5. Programmpfad und Argumente kontrollieren.
6. Dienstkonto und Berechtigungen prüfen.
7. Abhängigkeiten testen.
8. Portkonflikte und Ressourcen prüfen.
9. Konfiguration mit Herstellerwerkzeug validieren.
10. Einen einzelnen kontrollierten Startversuch durchführen.
11. Protokolle während dieses Versuchs beobachten.
12. Ergebnis dokumentieren und erneut bewerten.

Grundlegenden Dienststatus anzeigen:

[RO] Get-Service -Name "<DIENSTNAME>"

Erweiterte Dienstinformationen anzeigen:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name,
                  DisplayName,
                  State,
                  Status,
                  StartMode,
                  StartName,
                  ProcessId,
                  ExitCode,
                  ServiceSpecificExitCode

Status mit sc.exe prüfen:

[RO] sc.exe queryex "<DIENSTNAME>"

Wichtige Angaben:

Ein Exitcode 0 ist nur dann aussagekräftig, wenn der Dienst regulär beendet wurde. Ein Dienst kann trotzdem seine vorgesehene Funktion nicht bereitgestellt haben.

Konfiguration des Dienstes anzeigen:

[RO][SENS] sc.exe qc "<DIENSTNAME>"

Konfiguration über CIM anzeigen:

[RO][SENS] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name,
                  StartMode,
                  StartName,
                  PathName,
                  ServiceType,
                  DesktopInteract

Zu prüfen sind:

Wichtig bei Programmpfaden:

• Programmpfad und Argumente dürfen nicht verwechselt werden.
• Leerzeichen im Pfad erfordern korrekte Anführungszeichen.
• Relative Pfade können im Dienstkontext anders aufgelöst werden.
• Ein Netzlaufwerksbuchstabe aus einer Benutzersitzung steht einem Dienst normalerweise nicht automatisch zur Verfügung.
• Das Dienstkonto muss auf Programm, Arbeitsverzeichnis und Konfiguration zugreifen können.

Da PathName auch Argumente enthalten kann, darf die gesamte Zeichenfolge nicht ungeprüft an Test-Path übergeben werden.

Konfigurierte Zeichenfolge zunächst nur anzeigen:

[RO][SENS] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, PathName

Anschließend wird der tatsächliche ausführbare Pfad aus der Ausgabe ermittelt und separat geprüft:

[RO][FILE] Test-Path -LiteralPath "<AUSFÜHRBARE_DATEI>"

Dateiinformationen anzeigen:

[RO][FILE][SENS] Get-Item -LiteralPath "<AUSFÜHRBARE_DATEI>" |
    Select-Object FullName, Length, CreationTime, LastWriteTime, VersionInfo

Berechtigungen anzeigen:

[RO][FILE][SENS] Get-Acl -LiteralPath "<AUSFÜHRBARE_DATEI>" |
    Format-List

Zusätzlich prüfen:

• Ist die Datei tatsächlich vorhanden?
• Wurde sie kürzlich ersetzt oder verschoben?
• Passt die Architektur zum Betriebssystem?
• Sind benötigte Bibliotheken vorhanden?
• Blockiert Sicherheitssoftware die Ausführung?
• Liegt die Datei auf einem beim Start noch nicht verfügbaren Datenträger?
• Ist der Pfad lokal oder von einer Netzwerkressource abhängig?

Dienstkonto anzeigen:

[RO] Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'" |
    Select-Object Name, StartName, State, StartMode

Mögliche Kontotypen:

• LocalSystem,
• NT AUTHORITY\LocalService,
• NT AUTHORITY\NetworkService,
• virtuelles Dienstkonto,
• verwaltetes Dienstkonto,
• lokales Benutzerkonto,
• Domänenkonto.

Zu prüfen:

• Existiert das Konto?
• Ist es aktiviert oder gesperrt?
• Ist ein hinterlegtes Kennwort abgelaufen oder geändert worden?
• Besitzt es das Recht „Anmelden als Dienst“?
• Darf es die Programmdatei lesen und ausführen?
• Darf es Konfigurations- und Datenverzeichnisse verwenden?
• Darf es Zertifikate und private Schlüssel verwenden?
• Darf es auf Netzwerkressourcen zugreifen?
• Wurde das Konto kürzlich geändert?
• Funktioniert ein verwaltetes Dienstkonto ordnungsgemäß?

Ein manueller Programmstart als Administrator beweist nicht, dass das Programm unter dem tatsächlichen Dienstkonto funktioniert.

Die vollständige Fehlermeldung, das betroffene Produkt und die Windows-Version müssen immer mit dokumentiert werden. Die Tabelle ist eine Eingrenzungshilfe, kein Ersatz für die konkrete Herstellerdiagnose.

Service-Control-Manager-Ereignisse der letzten Stunde:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName      = "System"
    ProviderName = "Service Control Manager"
    StartTime    = (Get-Date).AddHours(-1)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Typische startbezogene Ereignisse filtern:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName      = "System"
    ProviderName = "Service Control Manager"
    Id           = 7000, 7001, 7009, 7011, 7023, 7024, 7031, 7034
    StartTime    = (Get-Date).AddHours(-24)
} |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

System- und Anwendungsereignisse im festen Zeitfenster verbinden:

[RO][SENS] $startTime = Get-Date "2026-07-31 09:10:00"
$endTime   = Get-Date "2026-07-31 09:20:00"

Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = $startTime
    EndTime   = $endTime
} |
    Sort-Object TimeCreated |
    Select-Object TimeCreated,
                  LogName,
                  ProviderName,
                  Id,
                  LevelDisplayName,
                  Message

Ein Dienst kann nach einem Fehlstart oder Absturz automatisch neu gestartet werden.

Konfigurierte Fehleraktionen anzeigen:

[RO] sc.exe qfailure "<DIENSTNAME>"

Zusätzlichen Fehleraktionsstatus anzeigen:

[RO] sc.exe qfailureflag "<DIENSTNAME>"

Mögliche Aktionen:

• keine Aktion,
• Dienst neu starten,
• Programm ausführen,
• Computer neu starten.

Prüffragen:

• Wird der Dienst automatisch neu gestartet?
• Nach welcher Wartezeit?
• Wie viele Versuche erfolgen?
• Wann wird der Fehlerzähler zurückgesetzt?
• Wird auch bei einem normalen Prozessende eine Fehleraktion ausgelöst?
• Verändert die Wiederherstellung die sichtbare PID?
• Verdeckt die Automatik einen wiederkehrenden Startfehler?

Wiederherstellungsregeln dürfen nicht ungeprüft verändert werden. Sie können die Verfügbarkeit und das Verhalten bei Abstürzen erheblich beeinflussen.

Ausführlichen Status anzeigen:

[RO][SENS][PRIV] sudo systemctl status "<DIENST>" --no-pager

Wichtige Zustände strukturiert anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=LoadState,ActiveState,SubState,UnitFileState,Result,MainPID,ExecMainCode,ExecMainStatus,StatusErrno,NRestarts

Prüfen, ob die Unit aktiviert ist:

[RO] systemctl is-enabled "<DIENST>"

Prüfen, ob sie fehlgeschlagen ist:

[RO] systemctl is-failed "<DIENST>"

Alle fehlgeschlagenen Units anzeigen:

[RO] systemctl --failed --no-pager

Wichtige Angaben:

Mögliche Result-Werte können unter anderem sein:

Beendigungsart:

Die konkrete Bedeutung von ExecMainStatus hängt davon ab, ob der Prozess regulär beendet oder durch ein Signal beendet wurde. Zusätzlich muss die Dokumentation des Programms geprüft werden.

Wirksame Unit einschließlich Drop-ins anzeigen:

[RO][FILE][SENS] systemctl cat "<DIENST>"

Wichtige Startparameter strukturiert anzeigen:

[RO][SENS] systemctl show "<DIENST>" \
  --property=Type,User,Group,ExecStart,ExecStartPre,ExecStartPost,WorkingDirectory,EnvironmentFiles,FragmentPath,DropInPaths

Unit-Datei formal prüfen:

[RO][FILE] systemd-analyze verify "<UNIT-DATEI>"

Zu prüfen sind:

• Type=,
• ExecStart=,
• ExecStartPre=,
• ExecStartPost=,
• User= und Group=,
• WorkingDirectory=,
• EnvironmentFile=,
• PIDFile=,
• RuntimeDirectory=,
• StateDirectory=,
• TimeoutStartSec=,
• Restart=,
• RestartSec=,
• StartLimitIntervalSec=,
• StartLimitBurst=.

systemd-analyze verify benötigt den tatsächlichen Pfad einer Unit-Datei. Der Pfad sollte mit systemctl show <DIENST> --property=FragmentPath ermittelt werden.

Konfigurierten Startbefehl anzeigen:

[RO][SENS] systemctl show "<DIENST>" --property=ExecStart

Datei des bekannten Programmpfads prüfen:

[RO][FILE] stat "<AUSFÜHRBARE_DATEI>"

Dateityp und Architektur prüfen:

[RO][FILE] file "<AUSFÜHRBARE_DATEI>"

Berechtigungen aller Pfadbestandteile anzeigen:

[RO][FILE] namei -l "<AUSFÜHRBARE_DATEI>"

Dynamische Bibliotheksabhängigkeiten eines geeigneten dynamischen ELF-Programms anzeigen:

[RO][FILE][SENS] ldd "<AUSFÜHRBARE_DATEI>"

Wichtiger Sicherheitshinweis:

ldd sollte nicht ungeprüft auf nicht vertrauenswürdige ausführbare Dateien angewendet werden. Abhängig von System und Binärdatei kann die Auswertung Sicherheitsrisiken besitzen.

Alternativ kann bei ELF-Dateien zunächst statisch geprüft werden:

[RO][FILE] readelf -d "<AUSFÜHRBARE_DATEI>"

Zu prüfen:

• Datei vorhanden,
• ausführbar,
• richtige Architektur,
• korrekter Interpreter,
• benötigte Bibliotheken vorhanden,
• Dienstkonto kann alle Pfadbestandteile durchlaufen,
• Arbeitsverzeichnis vorhanden,
• Dateisystem nicht schreibgeschützt,
• Sicherheitsmechanismen wie SELinux oder AppArmor berücksichtigt.

Konfiguriertes Konto anzeigen:

[RO] systemctl show "<DIENST>" --property=User,Group,DynamicUser

Benutzerkonto prüfen:

[RO] getent passwd "<DIENSTBENUTZER>"

Gruppenmitgliedschaften anzeigen:

[RO] id "<DIENSTBENUTZER>"

Arbeitsverzeichnis prüfen:

[RO] systemctl show "<DIENST>" --property=WorkingDirectory

Referenzierte Umgebungsdateien anzeigen:

[RO][SENS] systemctl show "<DIENST>" --property=EnvironmentFiles

Zu prüfen:

• Existiert der Dienstbenutzer?
• Existiert die konfigurierte Gruppe?
• Sind Dateirechte ausreichend?
• Ist ein dynamischer Benutzer vorgesehen?
• Existiert das Arbeitsverzeichnis?
• Kann das Konto Konfigurations- und Datendateien lesen?
• Kann es in erforderliche Verzeichnisse schreiben?
• Kann es privilegierte Ports oder Geräte verwenden?
• Blockieren SELinux, AppArmor oder systemd-Sandboxing den Zugriff?
• Sind Secrets für den Dienstkontext verfügbar?

Das Starten des Programms als root ist kein gültiger Nachweis für die Funktion unter dem tatsächlichen Dienstkonto.

Protokolle des aktuellen Systemstarts:

[RO][SENS][PRIV] sudo journalctl \
  -b \
  -u "<DIENST>" \
  --no-pager

Letzte 100 Einträge:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -n 100 \
  --output=short-iso \
  --no-pager

Fehler und schwerwiegendere Meldungen:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -p err \
  --since "1 hour ago" \
  --no-pager

Dienst- und Systemmeldungen im selben Zeitfenster:

[RO][SENS][PRIV] sudo journalctl \
  --since "2026-07-31 09:10:00" \
  --until "2026-07-31 09:20:00" \
  --output=short-iso \
  --no-pager

Kernelmeldungen berücksichtigen:

[RO][SENS][PRIV] sudo journalctl \
  -k \
  -b \
  -p warning \
  --no-pager

Neustartregeln anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=Restart,RestartUSec,NRestarts

Startbegrenzung anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=StartLimitIntervalUSec,StartLimitBurst,Result

Anzeichen:

• NRestarts steigt,
• PID wechselt fortlaufend,
• Prozesslaufzeit bleibt sehr kurz,
• Result=start-limit-hit,
• Journal zeigt wiederholte identische Startfehler,
• Dienst ist zwischen den Versuchen kurz erreichbar,
• Healthcheck schlägt fortlaufend fehl.

Fehlerstatus erst nach der Beweissicherung zurücksetzen:

[CHANGE][PRIV] sudo systemctl reset-failed "<DIENST>"

reset-failed:

• startet den Dienst nicht,
• löscht aber den gespeicherten Fehlerzustand,
• setzt bestimmte Zähler für Startbegrenzungen zurück,
• verändert damit Diagnosezustand.

Dieser Befehl darf deshalb erst nach Dokumentation von Result, NRestarts, Status und Journal verwendet werden.

Mögliche Fehlkonfigurationen:

• forking verwendet falsche oder fehlende PID-Datei,
• notify-Dienst sendet keine Bereitschaftsmeldung,
• oneshot wird fälschlich als dauerhaft laufender Prozess erwartet,
• Programm forkt, obwohl Type=simple ungeeignet konfiguriert wurde,
• Wrapperprozess beendet sich und systemd überwacht nicht den erwarteten Prozess,
• Startbefehl blockiert und erreicht den vorgesehenen Zustand nicht.

Der korrekte Diensttyp muss anhand der Programmdokumentation und des tatsächlichen Prozessverhaltens bestimmt werden.

Systemweiten Dienst prüfen:

[RO] launchctl print "system/<LABEL>"

Benutzerbezogenen Dienst prüfen:

[RO] launchctl print "gui/$(id -u)/<LABEL>"

Relevante Angaben können sein:

state
pid
runs
last exit code
program
arguments
reason
path

Deaktivierungsüberschreibungen prüfen:

[RO] launchctl print-disabled system

GUI-Domain des aktuellen Benutzers prüfen:

[RO] launchctl print-disabled "gui/$(id -u)"

Wichtig:

• Fehlende PID kann bei einem bedarfsgesteuerten Job normal sein.
• Ein von null abweichender letzter Exitstatus ist ein Diagnosehinweis.
• Eine steigende Anzahl unter runs kann auf wiederholte Startversuche hinweisen.
• Ein Job mit KeepAlive kann nach einem Fehler automatisch erneut gestartet werden.
• Häufige schnelle Fehlstarts können von launchd gedrosselt werden.

Bekannte systemweite plist anzeigen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Formale plist-Prüfung durchführen:

[RO][FILE] plutil -lint "/Library/LaunchDaemons/<LABEL>.plist"

Benutzerbezogene plist prüfen:

[RO][FILE][SENS] plutil -p "$HOME/Library/LaunchAgents/<LABEL>.plist"

Zu prüfen sind:

ProgramArguments ist ein Array. Das erste Element bezeichnet üblicherweise das auszuführende Programm, wenn nicht zusätzlich Program angegeben wurde.

Programmdatei prüfen:

[RO][FILE] stat "<AUSFÜHRBARE_DATEI>"

Dateityp und Architektur anzeigen:

[RO][FILE] file "<AUSFÜHRBARE_DATEI>"

Berechtigungen und erweiterte Zugriffslisten anzeigen:

[RO][FILE][SENS] ls -lde "<AUSFÜHRBARE_DATEI>"

Code-Signatur anzeigen und prüfen:

[RO][FILE][SENS] codesign \
  --verify \
  --deep \
  --strict \
  --verbose=2 \
  "<AUSFÜHRBARE_DATEI>"

Gatekeeper-Bewertung für einen geeigneten Anwendungstyp prüfen:

[RO][FILE][SENS] spctl \
  --assess \
  --type execute \
  --verbose=4 \
  "<AUSFÜHRBARE_DATEI>"

Hinweise:

• codesign prüft die Signatur, beweist aber nicht die vollständige Dienstfunktion.
• spctl ist nicht für jede Art von Binärdatei gleich aussagekräftig.
• Datenschutz- und Sicherheitsmechanismen können den Zugriff eines Daemons einschränken.
• Ein erfolgreicher Start im Terminal beweist nicht die Funktion innerhalb der launchd-Domain.

Nach Prozess suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "<PROZESS>"' \
  --style compact \
  --no-pager

Nach launchd- und Prozessmeldungen suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "launchd" OR process == "<PROZESS>"' \
  --style compact \
  --no-pager

Fehler und Faults anzeigen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate '(process == "launchd" OR process == "<PROZESS>") AND (messageType == error OR messageType == fault)' \
  --style compact \
  --no-pager

Live-Beobachtung während eines kontrollierten Startversuchs:

[TEST][SENS][PRIV] sudo log stream \
  --timeout 5m \
  --predicate 'process == "launchd" OR process == "<PROZESS>"' \
  --style compact

Wenn ein launchctl-Befehl einen numerischen Fehlercode liefert, kann dieser mit launchctl error lesbarer dargestellt werden.

Automatische Einordnung versuchen:

[RO] launchctl error <FEHLERCODE>

POSIX-Fehlerbereich angeben:

[RO] launchctl error posix <FEHLERCODE>

Mach-Fehlerbereich angeben:

[RO] launchctl error mach <FEHLERCODE>

Bootstrap-Fehlerbereich angeben:

[RO] launchctl error bootstrap <FEHLERCODE>

Die übersetzte Meldung beschreibt den technischen Fehlerbereich. Die konkrete Ursache muss weiterhin anhand von plist, Programmpfad, Berechtigungen und Protokollen bestimmt werden.

Ein Startversuch verändert den Dienstzustand und kann Folgeprozesse, Netzwerkverbindungen oder automatische Wiederherstellungsaktionen auslösen.

macOS – PID bei erfolgreichem kickstart ausgeben:

[CHANGE][PRIV] sudo launchctl kickstart \
  -p \
  "system/<LABEL>"

Ablauf:

1. Aktuellen Status und Protokolle sichern
2. Live-Protokollansicht vorbereiten
3. Genaue Startzeit notieren
4. Genau einen Startversuch ausführen
5. Rückgabemeldung vollständig erfassen
6. Dienststatus sofort prüfen
7. Prozess-ID und Laufzeit prüfen
8. Listener prüfen
9. Neue Protokollmeldungen sichern
10. Anwendungstest durchführen
11. Keine weiteren Versuche ohne neue Erkenntnis starten

Ein direkter Programmstart kann zusätzliche Fehlermeldungen auf der Konsole sichtbar machen. Er ist aber nicht automatisch sicher oder mit dem Dienststart gleichwertig.

Vorher prüfen:

• erlaubt der Hersteller einen Konsolen- oder Vordergrundmodus?
• ist der Dienstprozess wirklich beendet?
• würde eine zweite Instanz denselben Port oder dieselben Dateien verwenden?
• werden beim Start Datenbanken oder Dateien verändert?
• welches Benutzerkonto muss verwendet werden?
• welche Umgebungsvariablen setzt die Dienstverwaltung?
• welches Arbeitsverzeichnis wird erwartet?
• welche Limits und Sicherheitsrichtlinien gelten?
• existiert ein ausdrücklich dokumentierter Diagnoseparameter?

Der manuelle Start kann sich unterscheiden durch:

Deshalb wird kein generischer Direktstartbefehl verwendet. Der korrekte Diagnosemodus muss aus der offiziellen Dokumentation der jeweiligen Anwendung stammen.

• Syntaxfehler in der Konfiguration,
• fehlende Konfigurationsdatei,
• falscher Programmpfad,
• fehlende Bibliothek oder Laufzeitumgebung,
• falsche Prozessorarchitektur,
• Port bereits belegt,
• ungültiges Zertifikat oder fehlender privater Schlüssel,
• Dienstkonto besitzt keine Leserechte,
• Datenverzeichnis ist nicht beschreibbar,
• Volume oder Netzfreigabe fehlt,
• Datenbank nicht erreichbar,
• DNS-Auflösung fehlerhaft,
• Umgebungsvariable fehlt,
• Secret oder Kennwort ungültig,
• Lizenz fehlt oder ist abgelaufen,
• Datenmigration ist fehlgeschlagen,
• PID-Datei kann nicht erstellt werden,
• Sperrdatei einer alten Instanz ist vorhanden,
• Sicherheitssoftware blockiert die Ausführung,
• Speicher oder Dateideskriptoren sind erschöpft.

Ein Timeout bedeutet zunächst, dass ein erwarteter Zustand nicht innerhalb der vorgesehenen Zeit erreicht wurde.

Mögliche Ursachen:

• DNS-Abfrage dauert zu lange,
• Datenbank ist nicht bereit,
• Netzwerkspeicher antwortet nicht,
• Anwendung führt eine lange Migration durch,
• Dienst wartet auf eine gesperrte Datei,
• Portbindung blockiert,
• Dienst meldet seine Bereitschaft nicht korrekt,
• Diensttyp passt nicht zum Programmverhalten,
• Hardware oder Datenträger ist langsam,
• Entschlüsselung oder Zertifikatsprüfung hängt,
• Dienst wartet auf interaktive Eingabe,
• Endlosschleife während der Initialisierung.

Prüfung:

1. Startzeit genau feststellen
2. Letzte Meldung vor dem Timeout ermitteln
3. Prozesszustand während des Wartens prüfen
4. CPU- und I/O-Verhalten beobachten
5. Netzwerkverbindungen des Prozesses prüfen
6. Abhängigkeiten direkt testen
7. Herstellerdokumentation zur Initialisierung prüfen
8. Timeout nicht erhöhen, bevor die Warteursache bekannt ist

Eine Vergrößerung des Timeouts kann einen langsamen, aber legitimen Start ermöglichen. Sie kann jedoch ebenso einen eigentlichen Fehler nur länger verbergen.

Windows:

[RO] Get-NetTCPConnection `
  -State Listen `
  -LocalPort <PORT> `
  -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, LocalPort, OwningProcess

Linux:

[RO][PRIV] sudo ss -lntp "sport = :<PORT>"

macOS:

[RO][PRIV] sudo lsof \
  -nP \
  -iTCP:<PORT> \
  -sTCP:LISTEN

Wenn der Port belegt ist:

1. PID feststellen.
2. Prozessname bestimmen.
3. Dienstzuordnung prüfen.
4. Bindungsadresse kontrollieren.
5. Prüfen, ob eine alte Instanz läuft.
6. Container- oder Proxybelegung berücksichtigen.
7. Keinen Prozess ungeprüft beenden.
8. Sollkonfiguration und letzte Änderungen prüfen.

Mögliche Startfehler:

• Datenträger vollständig belegt,
• keine freien Inodes unter Linux,
• Arbeitsspeicher erschöpft,
• Auslagerung überlastet,
• Dateisystem schreibgeschützt,
• maximales Prozesslimit erreicht,
• Dateideskriptorlimit erreicht,
• temporäres Verzeichnis nicht verfügbar,
• Laufzeitverzeichnis kann nicht erstellt werden.

Besonders relevant sind Änderungen an:

• Programmversion,
• Dienstdatei oder plist,
• Windows-Dienstkonfiguration,
• systemd-Unit oder Drop-in,
• Dienstkonto oder Kennwort,
• Dateiberechtigungen,
• Zertifikaten,
• Port und Bindungsadresse,
• Firewall,
• Datenbankversion oder Schema,
• Bibliotheken und Laufzeitumgebung,
• Umgebungsvariablen,
• Secrets,
• Mounts und Volumes,
• Containern oder Images,
• Sicherheitssoftware,
• Betriebssystemupdates.

Zeitlicher Vergleich:

Letzter erfolgreicher Start
  → Änderung
  → erster fehlgeschlagener Start

Ein zeitlicher Zusammenhang ist ein starker Hinweis, aber noch kein Beweis. Die betroffene Konfiguration oder Komponente muss technisch geprüft werden.

[ ] Exakten Dienstnamen beziehungsweise Label bestätigt
[ ] Richtigen Server und richtige Umgebung bestätigt
[ ] Aktuellen Status gesichert
[ ] Exitcode und dienstspezifischen Exitcode erfasst
[ ] Relevante Protokolle vor neuem Startversuch gesichert
[ ] Startart und Deaktivierung geprüft
[ ] systemd-Maskierung beziehungsweise launchd-Override geprüft
[ ] Programmpfad und Startparameter geprüft
[ ] Programmdatei vorhanden
[ ] Dateityp und Architektur geprüft
[ ] Dienstkonto und Gruppe geprüft
[ ] Datei- und Verzeichnisrechte geprüft
[ ] Arbeitsverzeichnis geprüft
[ ] Umgebungs- und Konfigurationsdateien ermittelt
[ ] Formale Abhängigkeiten geprüft
[ ] Externe Backends geprüft
[ ] Portkonflikt ausgeschlossen
[ ] Speicherplatz und Arbeitsspeicher geprüft
[ ] Neustartregeln und Startbegrenzungen geprüft
[ ] Letzte Änderungen erfasst
[ ] Genau einen kontrollierten Startversuch durchgeführt
[ ] Prozess, PID und Laufzeit danach geprüft
[ ] Listener und Anwendungsfunktion geprüft
[ ] Ursache, Maßnahme und Ergebnis dokumentiert