Ein Dienst wird schrittweise von außen nach innen geprüft:

Wichtig: ping prüft nicht, ob ein Anwendungsdienst funktioniert. Ein Server kann ICMP-Anfragen beantworten, obwohl beispielsweise der Web-, Datenbank- oder Dateidienst ausgefallen ist.

Diese Zustände dürfen nicht miteinander verwechselt werden. Die Fehlersuche beginnt immer bei der niedrigsten noch nicht nachgewiesenen Funktionsebene.

Die folgenden Befehle liefern eine erste Übersicht. <DIENST> und <PORT> müssen durch die tatsächlichen Werte ersetzt werden.

launchctl print system/<DIENST> benötigt das Dienstlabel und nicht zwingend den sichtbaren Namen einer Anwendung. Benutzerbezogene LaunchAgents befinden sich außerdem nicht in der Systemdomäne.

1. Störung und betroffene Funktion genau beschreiben.
2. Zeitpunkt und Dauer der Störung erfassen.
3. Prüfen, welche Benutzer, Clients und Standorte betroffen sind.
4. Letzte Änderungen und bekannte Wartungsarbeiten ermitteln.
5. Servername und Zielsystem eindeutig bestimmen.
6. DNS-Auflösung und Netzwerkpfad überprüfen.
7. Erreichbarkeit des benötigten Ports testen.
8. Dienststatus, Prozess und Startart kontrollieren.
9. Kontrollieren, auf welcher Adresse und welchem Port der Dienst lauscht.
10. Abhängige Dienste und externe Systeme überprüfen.
11. System- und Anwendungsprotokolle für den Störungszeitraum auswerten.
12. CPU, Arbeitsspeicher, Datenträger und offene Dateien prüfen.
13. Konfiguration, Berechtigungen und Zertifikate kontrollieren.
14. Einen gezielten Funktionstest durchführen.
15. Erst danach eine geeignete Maßnahme planen.
16. Nach der Maßnahme Funktion und Nebenwirkungen überprüfen.
17. Ursache, Maßnahme und Ergebnis dokumentieren.

Vor einem Neustart müssen mindestens folgende Fragen beantwortet werden:

• Welche Benutzer und Anwendungen verwenden den Dienst?
• Gibt es laufende Transaktionen oder Dateioperationen?
• Hängen weitere Dienste von diesem Dienst ab?
• Wird der Dienst automatisch wieder gestartet?
• Existiert ein Cluster, Loadbalancer oder Failover-System?
• Gehen durch den Neustart Diagnoseinformationen verloren?
• Wurden die relevanten Protokolle bereits gesichert?
• Ist der Neustart betrieblich freigegeben?
• Wie wird die Funktion anschließend getestet?
• Gibt es eine Rückfallmöglichkeit?

Ein Neustart kann die Verfügbarkeit kurzfristig wiederherstellen, beseitigt aber nicht automatisch die eigentliche Fehlerursache. Vorher sollten Zustand, Zeitstempel, Fehlermeldungen und relevante Protokolle erfasst werden.

Bei einer Störung entsteht schnell der Wunsch, sofort einen Dienst neu zu starten oder eine bekannte Lösung auszuprobieren. Dadurch können jedoch wichtige Diagnoseinformationen verloren gehen.

Eine sinnvolle Haltung lautet:

1. Störungsmeldung nicht ungeprüft als Ursache übernehmen.
2. Beobachtungen von Vermutungen trennen.
3. Noch keine technische Ursache festlegen.
4. Zuerst den Umfang der Störung bestimmen.
5. Mit einfachen und möglichst lesenden Prüfungen beginnen.
6. Pro Arbeitsschritt nur eine wesentliche Veränderung durchführen.
7. Vor und nach jeder Maßnahme vergleichen.
8. Ergebnisse und Zeitpunkte dokumentieren.

Wichtig: Eine Fehlermeldung beschreibt häufig nur die Stelle, an der ein Fehler sichtbar wird – nicht die eigentliche Ursache.

Eine gute Fehlerbeschreibung beantwortet mindestens folgende Fragen:

Unzureichende Beschreibung:

„Der Server geht nicht.“

Verwertbare Beschreibung:

„Seit 09:15 Uhr erhalten alle geprüften Benutzer beim Anmelden an https://intranet.example.local den HTTP-Statuscode 503. Die Namensauflösung funktioniert und die Startseite ist erreichbar. Der Fehler tritt von mehreren Clients und Benutzerkonten aus auf.“

Beispiele für Schlussfolgerungen:

Diese Zuordnungen sind Arbeitshypothesen und noch kein endgültiger Ursachenbeweis.

Vor der technischen Prüfung müssen folgende Angaben geklärt werden:

Der sichtbare Name einer Anwendung, der Betriebssystem-Dienstname und der Prozessname können unterschiedlich sein.

Beispiel einer Dienstkette:

Client
  → DNS
  → Firewall oder Loadbalancer
  → Webserver
  → Anwendungsdienst
  → Datenbank
  → Verzeichnisdienst oder externe API

Die Störung kann an jeder Übergabestelle dieser Kette entstehen.

Die folgenden Befehle verändern den Systemzustand normalerweise nicht.

Hinweise:

• hostname --fqdn liefert nur dann ein sinnvolles Ergebnis, wenn Hostname und Namensauflösung korrekt konfiguriert sind.
• hostname -f kann unter macOS abhängig von der lokalen Namenskonfiguration fehlschlagen oder einen unerwarteten Namen liefern.
• systeminfo erzeugt eine umfangreiche Ausgabe. Für eine Dokumentation können relevante Zeilen gezielt ausgewählt werden.
• Zeitstempel müssen zusammen mit der Zeitzone dokumentiert werden, damit Client-, Server- und Netzwerkprotokolle richtig verglichen werden können.

Die Platzhalter <SUCHBEGRIFF>, <DIENST> und <PROZESS> müssen ersetzt werden.

Besonderheiten:

• Windows unterscheidet zwischen internem Dienstnamen und sichtbarem Anzeigenamen.
• Bei systemd gehört die Endung .service zum vollständigen Unit-Namen, kann bei eindeutigen Namen aber häufig weggelassen werden.
• launchctl list zeigt nicht automatisch alle Konfigurationsdetails eines Dienstes.
• launchctl print system/<DIENST> erwartet das tatsächliche launchd-Label.
• Ein laufender Prozess beweist noch nicht, dass der Dienst auf dem erwarteten Port lauscht oder fachlich korrekt arbeitet.

Auf dieser frühen Diagnosestufe sollte ein Dienst noch nicht neu gestartet werden. Zuerst müssen Status, Prozess, Port und relevante Protokolle erfasst werden.

Ein Vergleichstest verändert jeweils nur eine Prüfdimension. Dadurch lässt sich erkennen, welche Eigenschaft mit dem Fehler zusammenhängt.

Regel für einen aussagekräftigen Vergleich:

Gleicher Benutzer + anderer Client
oder
anderer Benutzer + gleicher Client
oder
gleicher Client + anderer Netzwerkweg

Werden mehrere Eigenschaften gleichzeitig verändert, ist das Ergebnis häufig nicht eindeutig.

Der direkte Zugriff auf ein Backend kann Sicherheitsregeln, Authentifizierung, TLS-Prüfungen oder den Loadbalancer umgehen. Er darf nur über einen freigegebenen administrativen Testweg erfolgen.

Bevor auf dem Server weitergesucht wird, sollte der Fehler möglichst reproduziert und genau protokolliert werden.

Beispiel:

Zeitpunkt:       2026-07-31T09:15:42+02:00
Client:          client-017
Betriebssystem:  Windows 11
Benutzerrolle:   Standardbenutzer
Ziel:            https://intranet.example.local/login
Aktion:          Anmeldeformular abgesendet
Ergebnis:        HTTP 503
Dauer:           Antwort nach ungefähr 2 Sekunden
Wiederholbar:    Ja
Vergleich:       Gleicher Fehler auf einem zweiten Client

Sensible Inhalte wie Kennwörter, Sitzungscookies, Zugriffstoken, private Schlüssel oder vollständige personenbezogene Daten dürfen nicht in die Dokumentation übernommen werden.

Viele Dienstfehler entstehen nach einer technischen oder organisatorischen Änderung. Ein zeitlicher Zusammenhang ist jedoch noch kein Beweis für die Ursache.

Zu prüfen sind insbesondere:

• Betriebssystem- und Anwendungsupdates,
• Änderungen an Konfigurationsdateien,
• Zertifikatswechsel,
• Kennwortänderungen von Dienstkonten,
• Änderungen an Gruppen oder Berechtigungen,
• Firewall- und Proxyänderungen,
• DNS- oder Loadbalanceränderungen,
• Datenbankmigrationen,
• Speicher- und Volumeänderungen,
• Container- oder Image-Updates,
• Neustarts und Stromausfälle,
• Sicherungs- und Wartungsaufgaben,
• Änderungen an externen APIs,
• abgelaufene Lizenzen oder Zertifikate,
• neu eingerichtete Überwachungs- oder Sicherheitssoftware.

Die Aussage „Seit dem Update besteht der Fehler“ ist eine wichtige Spur. Erst ein reproduzierbarer Zusammenhang oder ein passender Protokolleintrag macht daraus einen belastbaren Ursachenhinweis.

Die erste Eingrenzung ist ausreichend, wenn folgende Punkte beantwortet sind:

• Welche konkrete Funktion ist gestört?
• Welcher Server oder Dienst stellt diese Funktion bereit?
• Welche Benutzer, Geräte und Standorte sind betroffen?
• Welche Bereiche sind ausdrücklich nicht betroffen?
• Seit wann besteht die Störung?
• Ist der Fehler reproduzierbar?
• Welche Fehlermeldung oder welcher Statuscode erscheint?
• Welche Vergleichstests wurden durchgeführt?
• Welche Änderungen gingen der Störung voraus?
• Welche technische Ebene wird als Nächstes geprüft?
• Wurde der Ausgangszustand dokumentiert?

Beispiel einer abgeschlossenen Eingrenzung:

Alle geprüften Benutzer können die Startseite des Intranets über HTTPS aufrufen. Beim Absenden des Anmeldeformulars antwortet die Anwendung jedoch mit HTTP 503. Der Fehler tritt von Windows-, Linux- und macOS-Clients sowie an zwei Standorten auf. DNS-Auflösung und Netzwerkzugriff funktionieren. Als Nächstes werden deshalb Dienststatus, Prozess und Backend-Abhängigkeiten auf dem Anwendungsserver geprüft.

[ ] Konkrete gestörte Funktion erfasst
[ ] Vollständige Fehlermeldung erfasst
[ ] Datum, Uhrzeit und Zeitzone notiert
[ ] Betroffene Benutzer bestimmt
[ ] Betroffene Clients und Betriebssysteme bestimmt
[ ] Betroffene Standorte und Netzwerkwege bestimmt
[ ] Funktionierende Bereiche dokumentiert
[ ] Fehler reproduziert
[ ] Vergleichstest durchgeführt
[ ] Servername und Umgebung verifiziert
[ ] Dienstname, Prozess, Protokoll und Port zugeordnet
[ ] Abhängige Systeme aufgenommen
[ ] Letzte Änderungen erfragt
[ ] Ausgangszustand vor Änderungen dokumentiert
[ ] Keine Kennwörter, Token oder vertraulichen Daten gespeichert
[ ] Nächster technischer Prüfschritt festgelegt

Die Startart beschreibt, wann beziehungsweise wodurch ein Dienst gestartet werden soll. Der Dienststatus beschreibt seinen aktuellen Zustand.

Ein beendeter Dienst ist nicht automatisch fehlerhaft. Bedarfsgesteuerte Dienste laufen häufig nur, wenn sie tatsächlich benötigt werden.

Wichtige Unterschiede:

• Windows verwendet unter anderem die Startarten automatisch, manuell und deaktiviert.
• systemd unterscheidet den aktuellen Laufzustand von der Aktivierung für den Systemstart.
• Eine systemd-Unit kann zusätzlich masked sein. Dann kann sie nicht normal gestartet werden.
• macOS verwendet häufig bedarfsgesteuerte Dienste.
• Ein launchd-Job muss deshalb nicht dauerhaft als Prozess laufen.
• launchd unterscheidet verschiedene Ausführungsbereiche, sogenannte Domains.
• Ein fehlender Prozess bedeutet bei einem bedarfsgesteuerten launchd-Dienst nicht automatisch einen Fehler.

<DIENSTNAME> muss durch den internen Dienstnamen ersetzt werden.

Status eines bestimmten Dienstes:

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

Ausgewählte Statusinformationen anzeigen:

[RO] Get-Service -Name "<DIENSTNAME>" |
    Select-Object Name, DisplayName, Status, ServiceType

Mit einem Teil des Dienstnamens suchen:

[RO] Get-Service -Name "*<SUCHBEGRIFF>*" -ErrorAction SilentlyContinue

Mit einem Teil des Anzeigenamens suchen:

[RO] Get-Service -DisplayName "*<SUCHBEGRIFF>*" -ErrorAction SilentlyContinue

Alle beendeten Dienste anzeigen:

[RO] Get-Service |
    Where-Object Status -eq "Stopped" |
    Sort-Object DisplayName

Alle laufenden Dienste anzeigen:

[RO] Get-Service |
    Where-Object Status -eq "Running" |
    Sort-Object DisplayName

Dienststatus mit sc.exe abfragen:

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

Erweiterte Statusabfrage einschließlich Prozess-ID:

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

Typische Zustände sind:

Bleibt ein Dienst ungewöhnlich lange in StartPending oder StopPending, müssen Prozess, Abhängigkeiten und Ereignisprotokolle untersucht werden. Ein erzwungener Abbruch ist nicht der erste Diagnoseschritt.

Get-Service zeigt den Laufzustand, aber nicht alle Konfigurationsinformationen. Dafür kann die CIM-Klasse Win32_Service verwendet werden.

Vollständige Basiskonfiguration eines Dienstes:

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

Nur Startart und Dienstkonto anzeigen:

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

Konfiguration mit sc.exe prüfen:

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

Typische Werte für StartMode:

Typische Angaben von sc.exe qc:

[SENS]: Programmpfade und Startparameter können interne Verzeichnisstrukturen, Servernamen oder andere schützenswerte Konfigurationsangaben enthalten.

Die Startart Auto allein zeigt nicht immer, ob der automatische Start verzögert erfolgt.

Dienstkonfiguration über CIM prüfen:

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

Interpretation:

Falls DelayedAutoStart auf dem untersuchten System nicht ausgegeben wird, kann der Wert gezielt in der Dienstkonfiguration der Registrierung geprüft werden:

[RO] Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\<DIENSTNAME>" `
    -Name DelayedAutoStart `
    -ErrorAction SilentlyContinue

Dabei gilt üblicherweise:

Die Registrierung darf an dieser Stelle nur gelesen werden. Eine Änderung der Startart gehört in ein freigegebenes Änderungsverfahren.

<DIENST> muss durch den tatsächlichen Unit-Namen ersetzt werden, beispielsweise nginx.service.

Ausführlichen Status anzeigen:

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

Aktuellen Laufzustand abfragen:

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

Prüfen, ob die Unit für einen automatischen Start aktiviert ist:

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

Prüfen, ob die Unit fehlgeschlagen ist:

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

Wichtige Eigenschaften kompakt anzeigen:

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

Alle fehlgeschlagenen Units anzeigen:

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

Laufende Dienste anzeigen:

[RO] systemctl list-units \
  --type=service \
  --state=running \
  --no-pager

Installierte Service-Unit-Dateien und Aktivierungszustände anzeigen:

[RO] systemctl list-unit-files --type=service --no-pager

systemctl status zeigt zusätzlich einige aktuelle Protokollzeilen. Für eine vollständige Protokollanalyse wird später gezielt journalctl verwendet.

systemd verwendet mehrere voneinander unabhängige Zustandsangaben.

Ladezustand:

Aktivzustand:

Typische Aktivierungszustände:

Wichtige Kombinationen:

disabled bedeutet nicht automatisch „defekt“. Es bedeutet zunächst nur, dass die Unit nicht über ihre normalen Installationsverknüpfungen für den automatischen Start aktiviert ist.

Wirksame Unit-Datei einschließlich Ergänzungen anzeigen:

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

Pfad der geladenen Unit-Datei anzeigen:

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

Ergänzende Drop-in-Konfigurationen anzeigen:

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

Startbefehl und Dienstkonto anzeigen:

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

Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies "<DIENST>" --no-pager

Prüfen, wodurch die Unit für den Systemstart eingebunden ist:

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

Die Ausgabe von systemctl cat kann enthalten:

• ursprüngliche Unit-Datei,
• lokale Überschreibungen,
• Drop-in-Dateien,
• Start- und Stopbefehle,
• Dienstkonto,
• Neustartregeln,
• Abhängigkeiten,
• Umgebungsdateien.

[SENS]: Unit-Dateien können interne Pfade, Serveradressen oder Umgebungsdateien referenzieren. Die Inhalte von geheimen Umgebungsdateien dürfen nicht ungeprüft in Tickets oder Dokumentationen kopiert werden.

macOS unterscheidet unter anderem folgende Domains:

Benutzer-ID des aktuell angemeldeten Terminalbenutzers anzeigen:

[RO] id -u

Systemweiten Dienst prüfen:

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

Dienst im GUI-Kontext des aktuellen Benutzers prüfen:

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

Gesamten Systembereich anzeigen:

[RO] launchctl print system

GUI-Bereich des aktuellen Benutzers anzeigen:

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

Die Detailausgabe eines Dienstes kann unter anderem enthalten:

• Dienstlabel,
• aktuellen Zustand,
• Programmpfad,
• Startargumente,
• Prozess-ID,
• letzten Exitstatus,
• Dienstursprung auf dem Datenträger,
• Ausführungskontext,
• Startbedingungen.

Die Ausgabe von launchctl print ist für die manuelle Diagnose bestimmt. Apple garantiert ihr Format nicht als stabile Schnittstelle für Skripte.

Deaktivierungsüberschreibungen im Systembereich anzeigen:

[RO] launchctl print-disabled system

Deaktivierungsüberschreibungen im GUI-Bereich anzeigen:

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

Ein Eintrag mit true bedeutet, dass der Dienst in dieser Domain deaktiviert wurde. Ein Eintrag mit false bedeutet, dass eine Aktivierungsüberschreibung vorhanden sein kann.

Wichtig:

• Nicht jeder Dienst erscheint in print-disabled.
• Ein fehlender Eintrag bedeutet nicht automatisch, dass der Dienst aktiviert ist.
• Die effektive Startentscheidung kann zusätzlich von der plist-Konfiguration und Startbedingungen abhängen.
• Aktivierungsüberschreibungen werden außerhalb der eigentlichen plist-Datei verwaltet.
• Ein launchd-Job kann aktiviert, aber momentan ohne laufenden Prozess sein.
• Bedarfsgesteuerte Dienste werden möglicherweise erst beim Eintreten einer Startbedingung ausgeführt.

Typische Speicherorte sind:

Dateien unter /System/Library gehören zum Betriebssystem und dürfen nicht manuell verändert werden.

Konfigurationsdatei eines bekannten Drittanbieterdienstes lesbar anzeigen:

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

Konfigurationsdatei auf formale plist-Fehler prüfen:

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

Benutzerbezogenen Agenten anzeigen:

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

Typische Schlüssel einer launchd-plist:

RunAtLoad, KeepAlive und andere Startbedingungen sind nicht direkt mit den Windows-Startarten gleichzusetzen. launchd ist stark auf bedarfs- und ereignisgesteuertes Starten ausgelegt.

Windows:

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

Linux:

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

macOS:

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

Bei macOS sind insbesondere folgende Angaben relevant:

state
pid
last exit code
runs
reason

Die tatsächlich vorhandenen Felder können abhängig vom Dienst und von der macOS-Version abweichen.

Verdächtige Anzeichen:

• Prozess-ID wechselt in kurzen Abständen,
• Neustartzähler steigt,
• Dienststatus springt zwischen Start und Stopp,
• letzter Exitcode ist ungleich null,
• Dienst wird durch ein Signal beendet,
• Startgrenze oder Neustartbegrenzung wird erreicht,
• Dienst läuft nur wenige Sekunden,
• abhängiger Dienst ist nicht verfügbar.

Ein Exitcode ist zunächst nur ein technischer Hinweis. Seine genaue Bedeutung muss anhand der Dienst-, Hersteller- oder Betriebssystemdokumentation bestimmt werden.

Vor einem Start, Stopp oder Neustart sollten mindestens folgende Informationen gesichert werden:

Kompakte Dokumentationsvorlage:

Zeitpunkt:
Server:
Betriebssystem:
Dienstname:
Anzeigename beziehungsweise Label:
Dienststatus:
Startart beziehungsweise Aktivierung:
Prozess-ID:
Dienstkonto:
Programmpfad:
Letzter Exitcode:
Neustartzähler:
Abhängigkeiten:
Relevante Protokollmeldung:
Bewertung:
Nächster Prüfschritt:

Die folgenden Befehle sind keine reinen Diagnosebefehle. Sie verändern den Zustand und können Benutzer, Verbindungen oder Datenverarbeitung beeinträchtigen.

Wichtige Unterschiede:

• systemctl enable startet einen Dienst normalerweise nicht sofort.
• systemctl start aktiviert ihn nicht automatisch für spätere Systemstarts.
• systemctl enable --now würde beide Vorgänge kombinieren und ist deshalb eine weitergehende Änderung.
• launchctl kickstart -k beendet eine bereits laufende Instanz und startet sie neu.
• launchctl disable speichert eine Deaktivierungsüberschreibung, die Neustarts überdauern kann.
• Das Senden von SIGTERM beendet den aktuellen Prozess. launchd kann ihn abhängig von der Konfiguration erneut starten.
• Das Ändern der Startart beseitigt nicht die Ursache eines Startfehlers.

Diese Befehle sollten erst nach Sicherung des Ausgangszustands, Prüfung der Auswirkungen und betrieblicher Freigabe eingesetzt werden.

[ ] Internen Dienstnamen beziehungsweise launchd-Label ermittelt
[ ] Anzeigenamen und technischen Namen unterschieden
[ ] Richtigen Server und richtige Umgebung bestätigt
[ ] Aktuellen Dienststatus erfasst
[ ] Startart beziehungsweise Aktivierungszustand geprüft
[ ] Bedarfsgesteuerten Betrieb berücksichtigt
[ ] Deaktivierung oder Maskierung geprüft
[ ] Prozess-ID erfasst
[ ] Dienstkonto beziehungsweise Ausführungskontext geprüft
[ ] Programmpfad und Startargumente geprüft
[ ] Exitcode und dienstspezifischen Exitcode erfasst
[ ] Neustartzähler beziehungsweise wiederholte Starts geprüft
[ ] Abhängigkeiten aufgenommen
[ ] Ausgangszustand vor Änderungen dokumentiert
[ ] Noch keine ungeprüfte Zustandsänderung durchgeführt
[ ] Nächsten Diagnoseschritt festgelegt

Ein Dienst kann:

• genau einen Prozess verwenden,
• mehrere Prozesse starten,
• Kindprozesse erzeugen,
• mehrere Dienste in einem gemeinsamen Prozess ausführen,
• bedarfsgesteuert ohne dauerhaften Prozess arbeiten,
• nach einem Absturz automatisch eine neue PID erhalten.

Eine PID ist nicht dauerhaft. Nach dem Ende eines Prozesses kann dieselbe Nummer später einem anderen Prozess zugewiesen werden.

Die Platzhalter <PROZESS> und <PID> müssen ersetzt werden.

Prozess nach Namen suchen:

[RO] Get-Process -Name "<PROZESS>" -ErrorAction SilentlyContinue

Die Dateiendung .exe wird bei Get-Process -Name normalerweise nicht angegeben.

Prozess über die PID suchen:

[RO] Get-Process -Id <PID> -ErrorAction SilentlyContinue

Ausgewählte Prozessinformationen anzeigen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  StartTime,
                  CPU,
                  WorkingSet64,
                  PrivateMemorySize64,
                  VirtualMemorySize64,
                  HandleCount,
                  Responding

Alle Prozesse nach CPU-Zeit sortieren:

[RO] Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 Id, ProcessName, CPU, WorkingSet64

Alle Prozesse nach belegtem Arbeitsspeicher sortieren:

[RO] Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Id, ProcessName, WorkingSet64, CPU

Klassische Prozessübersicht:

[RO] tasklist

Bestimmten Prozess mit tasklist suchen:

[RO] tasklist /FI "PID eq <PID>"

Eigenschaften wie StartTime oder Path können bei geschützten Prozessen oder ohne ausreichende Rechte einen Zugriffsfehler verursachen.

Dienstname, Status und PID ermitteln:

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

Alle laufenden Dienste mit ihrer PID anzeigen:

[RO] Get-CimInstance Win32_Service |
    Where-Object State -eq "Running" |
    Select-Object Name, DisplayName, ProcessId, StartName |
    Sort-Object ProcessId

Alle Dienste innerhalb einer bestimmten PID suchen:

[RO] Get-CimInstance Win32_Service -Filter "ProcessId=<PID>" |
    Select-Object Name, DisplayName, State, StartName

Erweiterte Dienstabfrage mit sc.exe:

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

Dienstinformationen mit Prozessinformationen verbinden:

[RO][SENS] $service = Get-CimInstance Win32_Service -Filter "Name='<DIENSTNAME>'"
Get-CimInstance Win32_Process -Filter "ProcessId=$($service.ProcessId)" |
    Select-Object ProcessId,
                  ParentProcessId,
                  Name,
                  ExecutablePath,
                  CommandLine

Mehrere Windows-Dienste können sich einen gemeinsamen Hostprozess teilen. Das ist beispielsweise bei bestimmten svchost.exe-Instanzen üblich. Deshalb darf nicht allein anhand des Prozessnamens entschieden werden, welcher Dienst betroffen ist.

Prozessname, Elternprozess, Pfad und Befehlszeile anzeigen:

[RO][SENS] Get-CimInstance Win32_Process -Filter "ProcessId=<PID>" |
    Select-Object ProcessId,
                  ParentProcessId,
                  Name,
                  ExecutablePath,
                  CommandLine,
                  CreationDate

Elternprozess ermitteln:

[RO] $process = Get-CimInstance Win32_Process -Filter "ProcessId=<PID>"
Get-CimInstance Win32_Process -Filter "ProcessId=$($process.ParentProcessId)" |
    Select-Object ProcessId, ParentProcessId, Name, CreationDate

Direkte Kindprozesse anzeigen:

[RO][SENS] Get-CimInstance Win32_Process -Filter "ParentProcessId=<PID>" |
    Select-Object ProcessId, ParentProcessId, Name, CommandLine

Anzahl der Threads und Handles prüfen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  HandleCount,
                  @{Name="ThreadCount";Expression={$_.Threads.Count}}

Ausführungskonto des Prozesses abfragen:

[RO][PRIV] Invoke-CimMethod `
    -InputObject (Get-CimInstance Win32_Process -Filter "ProcessId=<PID>") `
    -MethodName GetOwner

[SENS]: Befehlszeilen können interne Pfade, Benutzernamen, Serveradressen oder unsicher übergebene Zugangsdaten enthalten. Die Ausgabe darf nicht ungeprüft weitergegeben werden.

Prozess nach Namen suchen:

[RO] pgrep -a "<PROZESS>"

Exakte Übereinstimmung des Prozessnamens verwenden:

[RO] pgrep -x -a "<PROZESS>"

Vollständige Befehlszeile durchsuchen:

[RO][SENS] pgrep -f -a "<SUCHMUSTER>"

Bestimmte PID untersuchen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd

Alle Prozesse ausführlich anzeigen:

[RO][SENS] ps -eo user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd

Nach CPU-Auslastung sortieren:

[RO] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,comm \
  --sort=-%cpu |
  head -n 16

Nach residentem Speicher sortieren:

[RO] ps -eo pid,ppid,user,stat,%cpu,%mem,rss,etime,comm \
  --sort=-rss |
  head -n 16

Interaktive Prozessübersicht:

[RO] top

Falls installiert:

[RO] htop

htop gehört nicht auf jeder Linux-Distribution zur Standardinstallation.

Linux stellt Prozessinformationen normalerweise unter /proc/<PID> bereit.

Ausführbare Datei bestimmen:

[RO][PRIV] sudo readlink -f "/proc/<PID>/exe"

Arbeitsverzeichnis anzeigen:

[RO][PRIV] sudo readlink -f "/proc/<PID>/cwd"

Prozessstatus anzeigen:

[RO][FILE][SENS] cat "/proc/<PID>/status"

Befehlszeile lesbar darstellen:

[RO][FILE][SENS] tr '\0' ' ' < "/proc/<PID>/cmdline"

Umgebungsvariablen anzeigen:

[RO][FILE][SENS][PRIV] sudo tr '\0' '\n' < "/proc/<PID>/environ"

Grenzwerte des Prozesses anzeigen:

[RO][FILE] cat "/proc/<PID>/limits"

Eingehängte Ressourcen des Prozesses anzeigen:

[RO][FILE][SENS] cat "/proc/<PID>/mountinfo"

Anzahl geöffneter Dateideskriptoren ermitteln:

[RO][PRIV] sudo find "/proc/<PID>/fd" -mindepth 1 -maxdepth 1 -printf '.' |
    wc -c

/proc/<PID>/environ kann Kennwörter, Token oder andere geheime Werte enthalten. Diese Abfrage darf nur bei berechtigtem Diagnosebedarf erfolgen. Die Ausgabe gehört nicht ungefiltert in ein Ticket.

Hauptprozess eines Dienstes anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=MainPID,ControlPID,ExecMainPID,ExecMainStartTimestamp

Prozessbaum der Unit im Status anzeigen:

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

Prozesse innerhalb der Unit beziehungsweise Control Group anzeigen:

[RO] systemd-cgls --unit "<DIENST>"

Ressourcennutzung von Control Groups beobachten:

[RO] systemd-cgtop

Hauptprozess anschließend mit ps untersuchen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd

Wichtig:

• MainPID=0 kann bedeuten, dass aktuell kein Hauptprozess vorhanden ist.
• Eine Unit kann mehrere Prozesse enthalten.
• Ein Kindprozess kann weiterlaufen, obwohl der ursprüngliche Startprozess bereits beendet wurde.
• Bei Type=oneshot kann eine erfolgreiche Unit aktiv sein, obwohl kein dauerhafter Prozess läuft.
• Der systemd-Status der gesamten Unit ist aussagekräftiger als die isolierte Betrachtung nur einer PID.

Prozess nach Namen oder Befehlszeile suchen:

[RO][SENS] pgrep -alf "<SUCHMUSTER>"

Exakten Prozessnamen suchen:

[RO] pgrep -x "<PROZESS>"

Bestimmte PID ausführlich anzeigen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,lstart,etime,state,%cpu,%mem,rss,vsz,command

Alle Prozesse ausführlich anzeigen:

[RO][SENS] ps -axo user,pid,ppid,lstart,etime,state,%cpu,%mem,rss,vsz,command

Prozesse nach aktueller CPU-Nutzung sortiert anzeigen:

[RO] ps -Arcwwxo pid,ppid,user,state,%cpu,%mem,rss,etime,command

Prozesse nach Speicherverbrauch sortiert anzeigen:

[RO] ps -Amcwwxo pid,ppid,user,state,%cpu,%mem,rss,etime,command

Interaktive Prozessübersicht nach CPU-Nutzung:

[RO] top -o cpu

Drei Messungen für eine bestimmte PID ausgeben:

[RO] top -l 3 -pid <PID> \
  -stats pid,command,cpu,mem,threads,state,time

Bei top -l ist die erste CPU-Messung möglicherweise noch nicht aussagekräftig, weil für eine belastbare Prozentberechnung ein zeitlicher Vergleich benötigt wird.

Systemweiten launchd-Dienst prüfen:

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

Benutzerbezogenen Dienst prüfen:

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

In der Ausgabe sind insbesondere folgende Angaben relevant:

state
pid
runs
last exit code
program
arguments

Gefundene PID anschließend untersuchen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,lstart,etime,state,%cpu,%mem,rss,vsz,command

Direkte Kindprozesse einer PID anzeigen:

[RO][SENS] pgrep -P <PID> -a

Geöffnete Dateien und Netzwerkressourcen des Prozesses anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID>

Ein launchd-Job kann geladen und funktionsfähig sein, obwohl momentan keine PID angezeigt wird. Das ist bei bedarfsgesteuerten Diensten möglich.

Hoher virtueller Speicher bedeutet nicht automatisch, dass entsprechend viel physischer Arbeitsspeicher belegt ist.

Der erste Buchstabe in der Spalte STAT beschreibt den grundlegenden Zustand.

Weitere Zeichen können zusätzliche Eigenschaften angeben:

Wichtige Bewertung:

• S ist bei Serverdiensten sehr häufig und normalerweise unauffällig.
• R ist nur zusammen mit Messdauer und CPU-Verbrauch zu bewerten.
• Ein kurzzeitiger D-Zustand kann normal sein.
• Ein dauerhaft im Zustand D verbleibender Prozess kann auf Datenträger-, Netzwerkdateisystem- oder Kernelprobleme hinweisen.
• Ein Z-Prozess verbraucht kaum Arbeitsspeicher, belegt aber weiterhin einen Eintrag in der Prozesstabelle.
• Ein Zombie wird durch den fehlerhaften oder nicht reagierenden Elternprozess bereinigt, nicht durch das Beenden des bereits beendeten Kindprozesses.

macOS verwendet ebenfalls Zustandszeichen, deren genaue Kombination mehrere Eigenschaften enthalten kann.

Abhängig von der Ausgabe können zusätzliche Zeichen erscheinen. Deshalb sollte bei Unklarheiten die lokale Handbuchseite herangezogen werden:

[RO] man ps

Prozesszustände dürfen nicht isoliert bewertet werden. Entscheidend ist, ob ein Zustand über einen längeren Messzeitraum bestehen bleibt und gleichzeitig eine Funktionsstörung vorliegt.

Eine einzelne Momentaufnahme reicht häufig nicht aus. CPU-Nutzung sollte über mehrere Messpunkte beobachtet werden.

Windows – zwei Messpunkte vergleichen:

[RO] Get-Process -Id <PID> |
    Select-Object Id, ProcessName, CPU, StartTime

Die Eigenschaft CPU enthält die bisher vom Prozess verbrauchte Prozessorzeit in Sekunden und nicht die momentane prozentuale Auslastung.

Linux – Prozess beobachten:

[RO] top -p <PID>

macOS – mehrere Messpunkte erfassen:

[RO] top -l 5 -s 2 -pid <PID> \
  -stats pid,command,cpu,mem,threads,state,time

Ein Prozess mit niedriger CPU-Nutzung kann trotzdem blockiert sein. Warten auf Ein-/Ausgabe benötigt häufig kaum Prozessorzeit.

Windows:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  WorkingSet64,
                  PrivateMemorySize64,
                  VirtualMemorySize64,
                  PagedMemorySize64

Linux:

[RO] ps -p <PID> -o pid,etime,%mem,rss,vsz,stat,comm

macOS:

[RO] ps -p <PID> -o pid,etime,%mem,rss,vsz,state,command

Hinweise auf ein mögliches Speicherleck:

• Speicherverbrauch steigt über längere Zeit kontinuierlich,
• der Verbrauch sinkt nach abgeschlossenen Aufgaben nicht wieder,
• Auslagerungsaktivität nimmt zu,
• der Prozess wird wegen Speichermangels beendet,
• die Dienstfunktion wird mit zunehmender Laufzeit langsamer,
• ein Neustart reduziert den Speicherverbrauch nur vorübergehend.

Ein Speicherleck lässt sich nicht durch einen einzelnen hohen Messwert beweisen. Dafür ist eine Zeitreihe unter vergleichbarer Last erforderlich.

Ein Prozess kann funktionsunfähig werden, obwohl er weiterhin läuft. Ursachen können erschöpfte Handles, Dateideskriptoren oder ungewöhnlich viele Threads sein.

Windows – Thread- und Handleanzahl:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  HandleCount,
                  @{Name="ThreadCount";Expression={$_.Threads.Count}}

Linux – Threads anzeigen:

[RO] ps -L -p <PID> -o pid,tid,psr,stat,%cpu,comm

Linux – geöffnete Ressourcen anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID>

macOS – Threads anzeigen:

[RO] ps -M -p <PID>

macOS – geöffnete Ressourcen anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID>

Verdächtig ist nicht allein eine hohe Anzahl, sondern insbesondere:

• kontinuierliches Wachstum,
• Erreichen eines konfigurierten Grenzwertes,
• Meldungen wie „too many open files“,
• fehlgeschlagene neue Verbindungen,
• steigende Threadzahl ohne entsprechende Last,
• Handles oder Dateien werden nach Aufgaben nicht freigegeben.

Eine neue PID kann bedeuten, dass ein Prozess neu gestartet wurde.

Windows – wiederholte Dienstabfrage:

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

Linux – Neustartzähler und Hauptprozess:

[RO] systemctl show "<DIENST>" \
  --property=MainPID,NRestarts,ActiveEnterTimestamp,ExecMainStartTimestamp,Result

macOS – Anzahl der Starts und aktuelle PID:

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

Anzeichen einer Neustartschleife:

• PID wechselt innerhalb kurzer Zeit,
• Prozesslaufzeit bleibt sehr kurz,
• systemd-Eigenschaft NRestarts steigt,
• launchd-Ausgabe zeigt eine steigende Anzahl unter runs,
• Windows-Ereignisprotokoll enthält wiederholte Start- und Stoppmeldungen,
• Anwendung protokolliert wiederholt denselben Startfehler,
• Dienststatus wechselt zwischen Starting, Running und Stopped,
• ein Überwachungswerkzeug startet den Prozess fortlaufend neu.

Ein automatisch neu gestarteter Dienst kann nach außen zeitweise erreichbar wirken. Die wechselnden PIDs und kurzen Unterbrechungen sind dann wichtige Diagnosehinweise.

Ein Prozess kann:

• CPU-intensiv arbeiten,
• auf Datenträgerzugriff warten,
• auf eine Netzwerkantwort warten,
• auf eine Datenbanksperre warten,
• auf einen anderen Thread warten,
• durch einen Deadlock blockiert sein,
• auf Benutzereingabe warten,
• zwar reagieren, aber extrem langsam sein.

Windows-Eigenschaft Responding:

[RO] Get-Process -Id <PID> |
    Select-Object Id, ProcessName, Responding

Diese Eigenschaft ist hauptsächlich bei Prozessen mit grafischer Benutzeroberfläche hilfreich. Sie ist kein zuverlässiger allgemeiner Funktionstest für Serverdienste.

Bessere Bewertung eines Serverprozesses:

1. Bleibt die PID stabil?
2. Verändert sich die CPU-Zeit?
3. Lauscht der Prozess auf dem erwarteten Port?
4. Nimmt er neue Verbindungen an?
5. Reagiert das Anwendungsprotokoll?
6. Gibt es blockierte Ein-/Ausgabe?
7. Steigt die Anzahl offener Verbindungen oder Dateien?
8. Zeigen Protokolle Zeitüberschreitungen oder Sperren?
9. Funktionieren abhängige Systeme?
10. Reagiert der Prozess auf einen kontrollierten Diagnosetest?

„Läuft“ und „reagiert“ sind unterschiedliche Zustände.

Die folgenden Befehle verändern den Systemzustand und können Datenverlust oder Dienstunterbrechungen verursachen.

Vorher prüfen:

[ ] PID unmittelbar vor der Maßnahme erneut verifiziert
[ ] Prozessname und Dienstzuordnung bestätigt
[ ] Aktive Benutzer und Verbindungen geprüft
[ ] Laufende Schreibvorgänge und Transaktionen berücksichtigt
[ ] Prozess- und Dienstprotokolle gesichert
[ ] Abhängige Dienste geprüft
[ ] Cluster- oder Failover-Verhalten berücksichtigt
[ ] Automatische Neustartregel geprüft
[ ] Betriebliche Freigabe vorhanden
[ ] Funktionstest nach der Maßnahme vorbereitet

Wichtige Unterschiede:

• SIGTERM gibt einem Unix-Prozess die Möglichkeit, kontrolliert zu beenden.
• SIGKILL kann nicht vom Prozess behandelt oder abgefangen werden.
• Stop-Process -Force erzwingt die Beendigung unter Windows.
• Wird nur der Prozess beendet, kann die Dienstverwaltung ihn automatisch erneut starten.
• Bei verwalteten Diensten sollte grundsätzlich die jeweilige Dienstverwaltung verwendet werden.
• Eine erzwungene Beendigung ist kein Ersatz für eine Ursachenanalyse.

Niemals eine alte, zuvor notierte PID ungeprüft verwenden. Die PID könnte inzwischen einem anderen Prozess gehören.

[ ] Dienst dem richtigen Prozess zugeordnet
[ ] PID unmittelbar aktuell ermittelt
[ ] Prozessname geprüft
[ ] Elternprozess und Kindprozesse geprüft
[ ] Ausführungskonto geprüft
[ ] Programmpfad und Befehlszeile geprüft
[ ] Startzeit und bisherige Laufzeit geprüft
[ ] Prozesszustand geprüft
[ ] CPU über mehrere Messpunkte beobachtet
[ ] Speicherverbrauch über einen Zeitraum bewertet
[ ] Threadanzahl geprüft
[ ] Handles beziehungsweise Dateideskriptoren geprüft
[ ] Geöffnete Dateien und Sockets bei Bedarf geprüft
[ ] Wechselnde PID ausgeschlossen oder dokumentiert
[ ] Automatische Neustarts geprüft
[ ] Exitcode und Protokolle gesichert
[ ] Noch keine ungeprüfte Prozessbeendigung durchgeführt
[ ] Nächsten Diagnoseschritt festgelegt

Beispiel einer TCP-Verbindung:

Client:  192.0.2.50:53124
Server:  192.0.2.20:443

Dabei ist 53124 normalerweise ein temporärer Clientport und 443 der bekannte Serverport.

Vor der Listenerprüfung müssen folgende Sollwerte bekannt sein:

Unzureichende Prüffrage:

„Ist Port 443 offen?“

Bessere Prüffragen:

• Lauscht der erwartete Prozess auf TCP-Port 443?
• Lauscht er auf der richtigen IPv4- oder IPv6-Adresse?
• Ist der Port lokal erreichbar?
• Ist er von einem vorgesehenen Clientnetz erreichbar?
• Antwortet dort tatsächlich das erwartete Anwendungsprotokoll?
• Wird der Zugriff durch einen Proxy oder Loadbalancer vermittelt?

Beispiel:

Ein Server besitzt folgende Adressen:

127.0.0.1
192.0.2.20
198.51.100.20

Der Dienst bindet sich an:

127.0.0.1:8080

Dann ist der Dienst normalerweise nicht direkt über 192.0.2.20:8080 oder 198.51.100.20:8080 erreichbar.

Bindet er sich an:

0.0.0.0:8080

nimmt er grundsätzlich auf allen lokalen IPv4-Adressen Verbindungen an. Firewall- und Routingregeln gelten zusätzlich.

Eine Wildcard-Bindung bedeutet nicht, dass der Port aus jedem Netzwerk erreichbar ist. Paketfilter, Routing, NAT, Sicherheitsgruppen und vorgeschaltete Systeme können den Zugriff weiterhin verhindern.

Alle TCP-Listener anzeigen:

[RO] Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort, LocalAddress

Wichtige Felder auswählen:

[RO] Get-NetTCPConnection -State Listen |
    Select-Object LocalAddress, LocalPort, State, OwningProcess |
    Sort-Object LocalPort, LocalAddress

Bestimmten TCP-Port prüfen:

[RO] Get-NetTCPConnection `
    -State Listen `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Bestimmte lokale Adresse und Port prüfen:

[RO] Get-NetTCPConnection `
    -State Listen `
    -LocalAddress "<IP-ADRESSE>" `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Klassische Alternative:

[RO] netstat -ano -p tcp

Nur TCP-Listener mit netstat:

[RO] netstat -ano -p tcp |
    Select-String "LISTENING"

Get-NetTCPConnection liefert strukturierte PowerShell-Objekte und ist deshalb für gezielte Filterungen besser geeignet als das Verarbeiten formatierter netstat-Ausgaben.

UDP besitzt keinen Verbindungszustand Listen. Stattdessen werden gebundene UDP-Endpunkte angezeigt.

Alle UDP-Endpunkte anzeigen:

[RO] Get-NetUDPEndpoint |
    Select-Object LocalAddress, LocalPort, OwningProcess |
    Sort-Object LocalPort, LocalAddress

Bestimmten UDP-Port prüfen:

[RO] Get-NetUDPEndpoint `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

Klassische Alternative:

[RO] netstat -ano -p udp

Wichtig:

• Das Vorhandensein eines UDP-Endpunkts zeigt nur eine lokale Bindung.
• UDP verwendet keinen TCP-Handshake.
• Ein UDP-Porttest kann deshalb nicht so eindeutig wie ein TCP-Verbindungstest bewertet werden.
• Eine fehlende UDP-Antwort kann normal sein, wenn die Testanfrage nicht dem erwarteten Anwendungsprotokoll entspricht.

TCP-Port und Prozess-ID ermitteln:

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

Zugehörigen Prozess anzeigen:

[RO] $connection = Get-NetTCPConnection `
    -State Listen `
    -LocalPort <PORT> `
    -ErrorAction SilentlyContinue

$connection |
    ForEach-Object {
        Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    } |
    Select-Object Id, ProcessName, StartTime

Prozess und Dienst über eine gefundene PID zuordnen:

[RO] Get-CimInstance Win32_Service -Filter "ProcessId=<PID>" |
    Select-Object Name, DisplayName, State, StartName

Alle TCP-Listener zusammen mit Prozessnamen anzeigen:

[RO] Get-NetTCPConnection -State Listen |
    ForEach-Object {
        $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue

        [PSCustomObject]@{
            LocalAddress = $_.LocalAddress
            LocalPort    = $_.LocalPort
            PID          = $_.OwningProcess
            ProcessName  = $process.ProcessName
        }
    } |
    Sort-Object LocalPort, LocalAddress

Mehrere Listener können dieselbe PID verwenden. Ebenso kann ein Prozess auf mehreren Adressen und Ports lauschen.

ss ist auf modernen Linux-Systemen das bevorzugte Werkzeug für Socketinformationen.

Alle lauschenden TCP-Sockets numerisch anzeigen:

[RO] ss -lnt

TCP-Listener einschließlich Prozessinformationen anzeigen:

[RO][PRIV] sudo ss -lntp

Gebundene UDP-Sockets anzeigen:

[RO] ss -lnu

UDP-Sockets einschließlich Prozessinformationen anzeigen:

[RO][PRIV] sudo ss -lnup

TCP- und UDP-Sockets gemeinsam anzeigen:

[RO][PRIV] sudo ss -lntup

Bedeutung wichtiger Optionen:

Nur IPv4-TCP-Listener:

[RO] ss -4 -lnt

Nur IPv6-TCP-Listener:

[RO] ss -6 -lnt

Ohne ausreichende Berechtigungen können Prozessname und PID in der Ausgabe fehlen.

Bestimmten TCP-Listener prüfen:

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

Bestimmten UDP-Port prüfen:

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

Offene Netzwerkressourcen einer PID anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

TCP-Listener einer PID anzeigen:

[RO][SENS][PRIV] sudo lsof \
    -nP \
    -a \
    -p <PID> \
    -iTCP \
    -sTCP:LISTEN

Bestimmten TCP-Port mit lsof prüfen:

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

Bestimmten UDP-Port mit lsof prüfen:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

lsof ist nicht auf jeder minimalen Linux-Installation vorhanden. In diesem Fall kann zunächst ss verwendet werden.

Alle TCP-Listener anzeigen:

[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

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

Gebundene UDP-Sockets anzeigen:

[RO][PRIV] sudo lsof -nP -iUDP

Bestimmten UDP-Port prüfen:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

Netzwerksockets einer bestimmten PID anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

TCP-Verbindungen und Listener mit netstat anzeigen:

[RO] netstat -anv -p tcp

UDP-Sockets mit netstat anzeigen:

[RO] netstat -anv -p udp

Unter macOS ist lsof für die Zuordnung von Netzwerkendpunkten zu Prozessen meist übersichtlicher als netstat.

Beispiel eines TCP-Listeners:

LISTEN  0  128  0.0.0.0:443  0.0.0.0:*

Interpretation:

Beispiel einer aufgebauten Verbindung:

192.0.2.20:443  192.0.2.50:53124  ESTABLISHED

Interpretation:

Lokaler Serverendpunkt:  192.0.2.20:443
Entfernter Client:       192.0.2.50:53124
Zustand:                 Verbindung aufgebaut

Bei der Auswertung muss zuerst bestimmt werden, welches System Client und welches System Server ist. Ein hoher temporärer Port gehört häufig zum Client.

Ein Dienst kann:

• nur auf IPv4 lauschen,
• nur auf IPv6 lauschen,
• getrennte IPv4- und IPv6-Sockets verwenden,
• einen IPv6-Wildcard-Socket verwenden,
• abhängig vom Betriebssystem IPv4-Verbindungen über einen IPv6-Socket annehmen.

Windows – IPv4-Listener eines Ports:

[RO] Get-NetTCPConnection -State Listen -LocalPort <PORT> |
    Where-Object LocalAddress -NotLike "*:*"

Windows – IPv6-Listener eines Ports:

[RO] Get-NetTCPConnection -State Listen -LocalPort <PORT> |
    Where-Object LocalAddress -Like "*:*"

Linux – IPv4 prüfen:

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

Linux – IPv6 prüfen:

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

macOS – IPv4 prüfen:

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

macOS – IPv6 prüfen:

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

Aus einer Bindung an [::]:<PORT> darf nicht ungeprüft geschlossen werden, dass IPv4 ebenfalls funktioniert. IPv4 und IPv6 müssen praktisch getrennt getestet werden.

Ein lokaler Test hilft zu unterscheiden, ob der Dienst grundsätzlich Verbindungen annimmt oder ob nur der externe Zugriff fehlschlägt.

Windows – IPv4-Loopback testen:

[TEST] Test-NetConnection 127.0.0.1 -Port <PORT>

Windows – konkrete Serveradresse testen:

[TEST] Test-NetConnection <SERVER-IP> -Port <PORT>

Linux – IPv4-Loopback testen:

[TEST] nc -vz -w 3 127.0.0.1 <PORT>

Linux – konkrete Serveradresse testen:

[TEST] nc -vz -w 3 <SERVER-IP> <PORT>

macOS – IPv4-Loopback testen:

[TEST] nc -vz -w 3 127.0.0.1 <PORT>

macOS – konkrete Serveradresse testen:

[TEST] nc -vz -w 3 <SERVER-IP> <PORT>

IPv6-Loopback unter Linux oder macOS testen:

[TEST] nc -6 -vz -w 3 ::1 <PORT>

Interpretation:

Ein erfolgreicher TCP-Porttest beweist nur, dass ein TCP-Verbindungsaufbau möglich war. Er beweist nicht, dass die Anwendung fachlich korrekt antwortet.

Der Test sollte aus dem tatsächlich betroffenen Netzwerk oder von einem vergleichbaren Client erfolgen.

Windows mit ausführlicher Ausgabe:

[TEST] Test-NetConnection <SERVER> -Port <PORT> -InformationLevel Detailed

Wichtige Ausgabe:

ComputerName
RemoteAddress
RemotePort
InterfaceAlias
SourceAddress
TcpTestSucceeded

Prüffragen:

• Wurde der erwartete Servername verwendet?
• Wurde der Name zur erwarteten IP-Adresse aufgelöst?
• Verwendet der Test die erwartete Quelladresse?
• Erfolgt der Test über das vorgesehene Netzwerkinterface?
• Ist der Port nur aus bestimmten Netzen erreichbar?
• Wird IPv4 oder IPv6 verwendet?
• Besteht zwischen Client und Server ein Proxy, VPN oder Loadbalancer?

Linux oder macOS:

[TEST] nc -vzu -w 3 <SERVER> <PORT>

Ein solcher Test kann jedoch häufig nicht zuverlässig bestätigen, dass:

• ein UDP-Dienst tatsächlich antwortet,
• die Anwendung die Testdaten verstanden hat,
• eine Firewall die Pakete verworfen hat,
• die Rückantwort den Client erreicht,
• der Dienst fachlich funktioniert.

Bessere UDP-Prüfung:

Bei UDP ist ein protokollspezifischer Funktionstest wesentlich aussagekräftiger als ein allgemeiner Portscan.

Wenn ein lokaler Porttest erfolgreich ist, ein entfernter Test aber fehlschlägt, kommen unter anderem folgende Ursachen infrage:

• Dienst bindet nur an Loopback,
• Dienst bindet an die falsche Netzwerkschnittstelle,
• lokale Hostfirewall blockiert externe Quellen,
• Netzwerkfirewall blockiert den Zielport,
• Routing zum Server oder zurück zum Client fehlt,
• falsches VLAN wird verwendet,
• Zugriff erfolgt über falsche IP-Adresse,
• IPv4 und IPv6 werden verwechselt,
• NAT- oder Portweiterleitung ist fehlerhaft,
• Sicherheitsgruppe oder Cloud-Firewall blockiert,
• Reverse Proxy oder Loadbalancer leitet nicht weiter,
• VPN-Richtlinie erlaubt das Zielnetz nicht,
• Dienst akzeptiert nur bestimmte Quelladressen.

Diagnosereihenfolge:

1. Listener und Bindungsadresse prüfen
2. Lokalen Test über Loopback durchführen
3. Lokalen Test über die Server-IP durchführen
4. Test aus demselben Subnetz durchführen
5. Test aus dem betroffenen Clientnetz durchführen
6. Hostfirewall prüfen
7. Netzwerkpfad und Zwischenfirewalls prüfen
8. Paketmitschnitt auf Client und Server erwägen

Ein Portkonflikt entsteht, wenn ein Prozess eine Adresse-Port-Kombination verwenden möchte, die bereits unvereinbar belegt ist.

Typische Fehlermeldungen:

Address already in use
Only one usage of each socket address is normally permitted
Failed to bind
Bind failed
EADDRINUSE
Port is already allocated

Windows:

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

[RO] Get-NetUDPEndpoint -LocalPort <PORT> |
    Select-Object LocalAddress, LocalPort, OwningProcess

Linux:

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

macOS – TCP:

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

macOS – UDP:

[RO][PRIV] sudo lsof -nP -iUDP:<PORT>

Prüffragen bei einem Konflikt:

• Welcher Prozess besitzt den Port?
• Gehört der Prozess zum erwarteten Dienst?
• Verwendet er eine Wildcard- oder Einzeladressbindung?
• Wurde eine zweite Dienstinstanz gestartet?
• Wurde der Port nach einer Aktualisierung verändert?
• Läuft ein alter Prozess weiter?
• Wird der Port durch einen Container oder Proxy veröffentlicht?
• Unterstützt die Anwendung mehrere Prozesse mit gemeinsamem Listener?
• Ist die Mehrfachbindung durch Socketoptionen ausdrücklich vorgesehen?

Einen unbekannten Prozess nicht allein deshalb beenden, weil er den gewünschten Port verwendet. Zuerst müssen Prozess, Dienst und betriebliche Funktion eindeutig zugeordnet werden.

Einzelne Verbindungen in TIME_WAIT oder CLOSE_WAIT sind noch kein Fehler. Auffällig sind große oder kontinuierlich wachsende Bestände über einen längeren Zeitraum.

Windows – Verbindungen einer PID:

[RO] Get-NetTCPConnection -OwningProcess <PID> |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State

Linux – alle TCP-Verbindungen einer PID über lsof:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -iTCP

macOS – alle TCP-Verbindungen einer PID:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -iTCP

Damit können unter anderem folgende Fragen beantwortet werden:

• Nimmt der Dienst Clientverbindungen an?
• Baut der Dienst Verbindungen zu einer Datenbank auf?
• Verbindet er sich mit einem Verzeichnisdienst?
• Greift er auf einen Proxy oder eine externe API zu?
• Bleiben ungewöhnlich viele Verbindungen in CLOSE_WAIT?
• Verwendet der Prozess den erwarteten Zielport?
• Baut er Verbindungen zu einer unerwarteten Adresse auf?

Remoteadressen, interne Servernamen und Verbindungsziele können sensible Infrastrukturinformationen darstellen.

Bei containerisierten oder weitergeleiteten Anwendungen können mehrere Portebenen vorhanden sein.

Client
  → Hostadresse: veröffentlichter Port
  → Firewall oder Proxy
  → Containeradresse: interner Port
  → Anwendungsprozess

Beispiel:

Host:       192.0.2.20:8443
Container:  172.18.0.5:443
Anwendung:  0.0.0.0:443 im Container

Prüfungen müssen deshalb unterscheiden zwischen:

• Listener auf dem Host,
• veröffentlichtem Containerport,
• internem Containerport,
• Listener innerhalb des Containers,
• Reverse-Proxy-Listener,
• Backend-Verbindung des Proxys,
• Host- und Containerfirewall,
• Container-Netzwerk und DNS.

Typische Fehler:

• Port wurde nicht veröffentlicht,
• Hostport und Containerport wurden vertauscht,
• Anwendung lauscht im Container nur auf 127.0.0.1,
• Reverse Proxy verwendet falschen Backendport,
• zwei Container beanspruchen denselben Hostport,
• Container wurde neu erstellt und erhielt eine andere interne Adresse,
• Anwendung startet später als der vorgeschaltete Proxy,
• Dienst lauscht nur auf IPv6 oder nur auf IPv4.

Die allgemeine Socketprüfung bleibt gleich, muss aber in jedem relevanten Netzwerk-Namespace beziehungsweise auf jeder Weiterleitungsstufe wiederholt werden.

[ ] Erwartetes Protokoll bestimmt
[ ] Erwarteten Port bestimmt
[ ] Erwartete Bindungsadresse bestimmt
[ ] IPv4 und IPv6 berücksichtigt
[ ] Dienststatus geprüft
[ ] Prozess und aktuelle PID geprüft
[ ] TCP-Listener beziehungsweise UDP-Endpunkt gesucht
[ ] Port dem richtigen Prozess zugeordnet
[ ] Loopback-Bindung ausgeschlossen oder als vorgesehen bestätigt
[ ] Wildcard- oder Einzeladressbindung bewertet
[ ] Lokalen Test über Loopback durchgeführt
[ ] Lokalen Test über die Serveradresse durchgeführt
[ ] Test aus dem betroffenen Clientnetz durchgeführt
[ ] Aufgelöste Zieladresse kontrolliert
[ ] TCP-Verbindungszustände geprüft
[ ] Portkonflikt ausgeschlossen
[ ] Proxy-, Loadbalancer- oder Containerstufe berücksichtigt
[ ] UDP nur mit geeignetem Protokolltest bewertet
[ ] Noch keine ungeprüfte Prozessbeendigung durchgeführt
[ ] Nächsten Diagnoseschritt dokumentiert

Betriebssystemwerkzeuge zeigen normalerweise nur die formal registrierten Abhängigkeiten. Externe Datenbanken, DNS-Server, APIs oder Netzwerkspeicher erscheinen dort häufig nicht.

Eine Anwendung kann beispielsweise folgende Kette besitzen:

Benutzer
  → Client
  → DNS
  → Netzwerk und Firewall
  → Loadbalancer
  → Reverse Proxy
  → Webserver
  → Anwendungsdienst
  → Datenbank
  → Verzeichnisdienst
  → Netzwerkspeicher
  → externe API

Für jede Verbindung sollten folgende Informationen erfasst werden:

Praktische Dokumentationsform:

Beispiele:

• Eine Webanwendung kann ihre Startseite ohne Datenbank ausliefern, aber keine Benutzer anmelden.
• Ein Maildienst kann Nachrichten zwischenspeichern, obwohl das Zielsystem vorübergehend nicht erreichbar ist.
• Ein Cluster kann beim Ausfall einer Instanz weiterarbeiten.
• Ein Dienst kann starten, obwohl ein optionales Monitoring-Backend fehlt.
• Eine Anwendung kann nach dem Start weiterarbeiten, obwohl der Konfigurationsdienst später ausfällt.

Der Ausfall einer Abhängigkeit führt nicht immer zum vollständigen Dienststillstand. Teilfunktionen und verzögerte Fehler müssen deshalb ausdrücklich geprüft werden.

<DIENSTNAME> muss durch den internen Dienstnamen ersetzt werden.

Dienst und erforderliche Systemdienste anzeigen:

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

Nur die erforderlichen Dienste übersichtlich anzeigen:

[RO] (Get-Service -Name "<DIENSTNAME>").ServicesDependedOn |
    Select-Object Name, DisplayName, Status

Dienste anzeigen, die vom untersuchten Dienst abhängen:

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

Abhängige Dienste übersichtlich anzeigen:

[RO] (Get-Service -Name "<DIENSTNAME>").DependentServices |
    Select-Object Name, DisplayName, Status

Dienst und beide Abhängigkeitsrichtungen erfassen:

[RO] $service = Get-Service -Name "<DIENSTNAME>"

$service | Select-Object Name, DisplayName, Status

"Benötigte Dienste:"
$service.ServicesDependedOn |
    Select-Object Name, DisplayName, Status

"Abhängige Dienste:"
$service.DependentServices |
    Select-Object Name, DisplayName, Status

Wichtig:

• ServicesDependedOn zeigt Dienste, die der untersuchte Dienst benötigt.
• DependentServices zeigt Dienste, die den untersuchten Dienst benötigen.
• Beide Richtungen sind vor einem Stopp oder Neustart relevant.
• Nicht jede funktionale Anwendungsabhängigkeit ist beim Service Control Manager registriert.

Konfiguration einschließlich eingetragener Abhängigkeiten anzeigen:

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

Relevant ist insbesondere der Abschnitt:

DEPENDENCIES

Direkt abhängige Dienste anzeigen:

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

Erweiterte Dienstinformationen anzeigen:

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

Interpretation:

sc.exe qc kann Programmpfade, Dienstkonten und interne Konfigurationsinformationen anzeigen. Die Ausgabe sollte deshalb als potenziell sensibel behandelt werden.

Benötigte Dienste samt Startart und Konto untersuchen:

[RO] $requiredServices = (Get-Service -Name "<DIENSTNAME>").ServicesDependedOn

foreach ($requiredService in $requiredServices) {
    Get-CimInstance Win32_Service `
        -Filter "Name='$($requiredService.Name)'" |
        Select-Object Name,
                      DisplayName,
                      State,
                      StartMode,
                      StartName,
                      ProcessId,
                      ExitCode
}

Mögliche Auffälligkeiten:

• erforderlicher Dienst ist beendet,
• erforderlicher Dienst ist deaktiviert,
• Dienst hängt in StartPending,
• Dienst läuft unter einem falschen Konto,
• Dienstprozess besitzt keine PID,
• Exitcode ist ungleich null,
• benötigter Dienst wird wiederholt neu gestartet,
• Abhängigkeitsdefinition enthält einen nicht mehr vorhandenen Dienst.

Ein laufender erforderlicher Dienst kann trotzdem funktional gestört sein. Nach dem Status müssen Listener, Protokoll und tatsächliche Funktion geprüft werden.

Direkte und indirekte Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies "<DIENST>" --no-pager

Nur unmittelbare Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies \
  --plain \
  --no-pager \
  "<DIENST>"

Rückwärts gerichtete Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

Abhängigkeiten und Reihenfolgenbeziehungen strukturiert anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=Requires,Wants,Requisite,BindsTo,PartOf,After,Before,Conflicts

Wirksame Unit-Konfiguration anzeigen:

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

Status abhängiger Units prüfen:

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

systemctl list-dependencies zeigt systemd-Units. Eine in der Anwendung konfigurierte Datenbank oder API wird nur dann sichtbar, wenn dafür ausdrücklich eine systemd-Beziehung definiert wurde.

Besonders wichtig:

Requires=  ist nicht dasselbe wie After=
Wants=     ist nicht dasselbe wie After=
After=     legt Reihenfolge fest, aber keine zwingende Anforderung
Before=    legt Reihenfolge fest, aber keine zwingende Anforderung

Beispiel:

[Unit]
Requires=postgresql.service
After=network-online.target postgresql.service

Mögliche Interpretation:

• Der Dienst besitzt eine starke Anforderung an postgresql.service.
• Er soll nach postgresql.service gestartet werden.
• Er soll außerdem nach network-online.target gestartet werden.
• Das Erreichen von network-online.target beweist nicht, dass eine bestimmte entfernte Datenbank tatsächlich erreichbar ist.

Für eine zuverlässige Bewertung müssen Anforderungs- und Reihenfolgedirektiven gemeinsam betrachtet werden.

Vorwärts gerichtete Frage:

Was benötigt dieser Dienst?

[RO] systemctl list-dependencies "<DIENST>" --no-pager

Rückwärts gerichtete Frage:

Welche Units benötigen diesen Dienst?

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

Nur Abhängigkeiten vor einem Neustart prüfen:

[RO] systemctl show "<DIENST>" \
  --property=RequiredBy,WantedBy,ConsistsOf,PartOf

Bewertung vor einer Maßnahme:

launchd besitzt laut Apple kein allgemeines ausdrückliches Abhängigkeitsmodell wie systemd. Dienstinteraktionen sollen möglichst über bedarfsgesteuerte IPC-Mechanismen gelöst werden.

Deshalb müssen mehrere Informationsquellen kombiniert werden.

Systemweiten Dienst anzeigen:

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

Benutzerbezogenen Dienst anzeigen:

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

Konfigurationsdatei eines bekannten Drittanbieterdienstes anzeigen:

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

Benutzerbezogenen LaunchAgent anzeigen:

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

In der plist können unter anderem folgende Auslöser relevant sein:

Der Schlüssel OtherJobEnabled bildet keine harte, zuverlässige Dienstabhängigkeit wie ein allgemeines Abhängigkeitsmodell. Apple beschreibt solche Bedingungen als Hinweise und empfiehlt bedarfsgesteuerte IPC-Mechanismen.

Funktionale Abhängigkeiten können an folgenden Stellen dokumentiert oder konfiguriert sein:

• Herstellerdokumentation,
• Architekturdiagramm,
• Betriebshandbuch,
• Konfigurationsdatei,
• Umgebungsvariable,
• Dienststartparameter,
• Containerdefinition,
• Reverse-Proxy-Konfiguration,
• DNS-Eintrag,
• Zertifikatskonfiguration,
• Mount-Konfiguration,
• Secret- oder Credential-Verwaltung,
• Anwendungsprotokoll,
• Überwachungssystem,
• Quellcode oder Deploymentbeschreibung.

Typische Konfigurationsbegriffe:

host
hostname
server
endpoint
url
uri
database
db_host
connection_string
ldap
smtp
proxy
upstream
backend
api
mount
share
certificate
key
timeout
retry

Konfigurationsdateien und Umgebungsvariablen können Geheimnisse enthalten. Nicht wahllos nach Inhalten suchen oder vollständige Dateien in Tickets kopieren.

Bereits aufgebaute Verbindungen können Hinweise auf verwendete Backends liefern.

Windows:

[RO][SENS] Get-NetTCPConnection -OwningProcess <PID> |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State

Linux:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

macOS:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

Damit können Hinweise gefunden werden auf:

• Datenbankserver,
• Authentifizierungsserver,
• SMTP-Server,
• Proxys,
• externe APIs,
• Clusterknoten,
• Objekt- oder Netzwerkspeicher,
• Monitoring- und Protokollserver.

Einschränkungen:

• Nur aktuell geöffnete Verbindungen sind sichtbar.
• Kurzlebige Verbindungen können zwischen zwei Abfragen fehlen.
• Ein Ziel kann über einen Proxy vermittelt werden.
• IP-Adressen allein beweisen nicht die fachliche Funktion des Zielsystems.
• UDP-Kommunikation ist schwieriger zu bewerten.
• Eine aktuell fehlende Verbindung kann bei Leerlauf normal sein.

Wenn ein Dienst ein Backend über einen Namen anspricht, muss genau dieser Name aus dem Kontext des Dienstservers geprüft werden.

Zu prüfen:

• Wird der richtige Name verwendet?
• Wird die erwartete IP-Adresse geliefert?
• Existieren unerwartete alte Adressen?
• Gibt es unterschiedliche Ergebnisse auf Client und Server?
• Wird ein Suchsuffix benötigt?
• Verwendet die Anwendung einen vollständig qualifizierten Namen?
• Bevorzugt die Anwendung IPv6?
• Ist der DNS-Server aus dem Dienstkontext erreichbar?
• Wurde ein DNS-Eintrag kürzlich geändert?

Eine erfolgreiche DNS-Abfrage beweist nur die Namensauflösung. Der zurückgegebene Zielserver muss anschließend über das erforderliche Protokoll geprüft werden.

Windows:

[TEST] Test-NetConnection "<BACKEND>" -Port <PORT>

Linux:

[TEST] nc -vz -w 3 "<BACKEND>" <PORT>

macOS:

[TEST] nc -vz -w 3 "<BACKEND>" <PORT>

Mögliche Ergebnisse:

Der Test muss vom tatsächlichen Anwendungsserver oder aus einem technisch gleichwertigen Netzwerkpfad erfolgen. Ein erfolgreicher Test vom Administrator-Client beweist nicht, dass der Dienstserver denselben Zugriff besitzt.

Nur Antwortheader eines HTTP- oder HTTPS-Endpunkts anfordern:

Ausführliche TLS- und Verbindungsdiagnose:

Zu prüfen:

• Wird die erwartete IP-Adresse verwendet?
• Ist der TCP-Verbindungsaufbau erfolgreich?
• Funktioniert der TLS-Handshake?
• Passt der Zertifikatsname?
• Welcher HTTP-Statuscode wird geliefert?
• Antwortet der erwartete Server?
• Erfolgt eine unerwartete Weiterleitung?
• Ist eine Authentifizierung erforderlich?
• Wie lange dauert die Antwort?

-v kann Header und andere sensible Informationen anzeigen. Zugangstoken oder Sitzungscookies dürfen nicht in die Befehlszeile oder Dokumentation übernommen werden.

Zu prüfen:

• Ist das Dateisystem eingehängt?
• Zeigt der Pfad auf das erwartete Ziel?
• Ist ausreichend Speicherplatz vorhanden?
• Sind unter Linux noch Inodes verfügbar?
• Ist das Dateisystem schreibgeschützt?
• Besitzt das Dienstkonto die erforderlichen Rechte?
• Ist ein Netzwerkmount nur scheinbar vorhanden, aber nicht erreichbar?
• Bestehen Dateisperren?
• Hat sich der Mountpfad geändert?
• Ist das Volume nach einem Neustart automatisch eingebunden worden?

Schreibtests verändern das Dateisystem und dürfen nur gezielt, mit freigegebenem Testpfad und anschließendem Aufräumen durchgeführt werden.

Falsche Systemzeit kann unter anderem folgende Funktionen beeinträchtigen:

• Kerberos-Authentifizierung,
• Zertifikatsprüfung,
• signierte Tokens,
• Protokollkorrelation,
• zeitgesteuerte Aufgaben,
• Datenbankreplikation,
• Clusterentscheidungen,
• Ablaufzeiten und Cache-Gültigkeit.

Prüfung:

• Stimmen Datum und Uhrzeit?
• Ist die richtige Zeitzone eingestellt?
• Ist die Zeitquelle erreichbar?
• Sind Client, Dienstserver und Backend ausreichend synchron?
• Stimmen Protokollzeitstempel tatsächlich überein?
• Verwendet eine Anwendung UTC, während eine andere lokale Zeit protokolliert?

Typische abhängige Identitätsdienste:

• Active Directory,
• LDAP oder LDAPS,
• Kerberos,
• RADIUS,
• lokale Benutzerverwaltung,
• OAuth- oder OpenID-Connect-Anbieter,
• SAML-Identitätsanbieter,
• Zertifikats- oder Smartcard-Infrastruktur.

Vor einer Anmeldeprüfung kontrollieren:

1. Wird der Identitätsserver korrekt aufgelöst?
2. Ist der erforderliche Port erreichbar?
3. Ist die Systemzeit synchron?
4. Ist das Dienstkonto aktiv?
5. Ist das Kennwort beziehungsweise Secret gültig?
6. Ist das Konto gesperrt?
7. Besitzt das Konto die erforderlichen Rechte?
8. Ist das Serverzertifikat gültig?
9. Funktioniert nur die Anmeldung nicht oder auch die gesamte Anwendung?
10. Sind alle Benutzer oder nur einzelne Konten betroffen?

Kennwörter, Tokens und private Schlüssel dürfen niemals in Diagnoseausgaben, Tickets oder BookStack-Beispiele kopiert werden.

Wenn mehrere Dienste gleichzeitig ausfallen, sollte nach einer gemeinsamen Komponente gesucht werden.

Vorgehen:

1. Betroffene Dienste auflisten
2. Zeitpunkt jedes Ausfalls vergleichen
3. Gemeinsame DNS-, Netzwerk- und Speicherpfade bestimmen
4. Gemeinsame Datenbanken und Identitätsdienste bestimmen
5. Gemeinsame Änderungen ermitteln
6. Gemeinsame Abhängigkeit direkt prüfen
7. Nach Wiederherstellung alle abhängigen Funktionen testen

Ein Dienst kann laut Betriebssystem gestartet worden sein, obwohl seine Funktion noch nicht vollständig bereitsteht.

Beispiel:

00:00 Datenbankprozess startet
00:02 Dienstverwaltung meldet „läuft“
00:05 Datenbank führt Wiederherstellung aus
00:40 Datenbank nimmt Anmeldungen an

Startet die Anwendung bereits bei Sekunde 3, kann ihre Verbindung fehlschlagen, obwohl der Datenbankdienst formal läuft.

Mögliche Lösungen innerhalb eines geplanten Änderungsverfahrens:

• geeignete Bereitschaftsprüfung,
• Wiederholungsversuche mit Begrenzung,
• zunehmende Wartezeiten zwischen Versuchen,
• sinnvoller Verbindungstimeout,
• korrekte systemd-Abhängigkeit,
• orchestrierte Healthchecks,
• Start erst nach erfolgreichem Backendtest,
• Warteschlange für vorübergehend nicht verarbeitbare Aufgaben.

Eine feste Wartezeit ist häufig weniger zuverlässig als eine echte Bereitschaftsprüfung.

Vor dem Neustart eines gemeinsam verwendeten Dienstes müssen die abhängigen Verbraucher bestimmt werden.

Windows:

[RO] (Get-Service -Name "<DIENSTNAME>").DependentServices |
    Select-Object Name, DisplayName, Status

Linux:

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

macOS:

Da launchd kein allgemeines ausdrückliches Abhängigkeitsmodell besitzt, müssen zusätzlich geprüft werden:

• Herstellerdokumentation,
• aktive Netzwerkverbindungen,
• Konfigurationsdateien,
• Architekturübersicht,
• Monitoring,
• Anwendungsprotokolle,
• bekannte Verbraucher des Dienstes.

Freigabecheck:

[ ] Alle bekannten Verbraucher identifiziert
[ ] Aktive Sitzungen und Transaktionen geprüft
[ ] Cluster- oder Failover-Verhalten geprüft
[ ] Wiederverbindungsverhalten der Clients bekannt
[ ] Neustartreihenfolge festgelegt
[ ] Wartungsfenster beziehungsweise Freigabe vorhanden
[ ] Diagnoseinformationen vorab gesichert
[ ] Funktionstests für alle wichtigen Verbraucher vorbereitet
[ ] Rückfallmöglichkeit festgelegt

Empfohlene Reihenfolge:

1. Hauptfunktion und Fehlermeldung bestimmen.
2. Formale Dienstabhängigkeiten erfassen.
3. Architektur und funktionale Abhängigkeiten ergänzen.
4. Kritische und optionale Abhängigkeiten kennzeichnen.
5. Namen der Zielsysteme prüfen.
6. DNS-Auflösung prüfen.
7. Netzwerkport vom tatsächlichen Dienstserver prüfen.
8. TLS- und Zertifikatsprüfung durchführen.
9. Protokollspezifischen Funktionstest durchführen.
10. Authentifizierung mit einem freigegebenen Testkonto prüfen.
11. Speicher- und Ressourcenabhängigkeiten prüfen.
12. Zeitstempel der beteiligten Systeme vergleichen.
13. Protokolle auf Quelle und Ziel korrelieren.
14. Gemeinsame Abhängigkeiten anderer gestörter Dienste prüfen.
15. Erst nach gesicherter Ursache eine Änderung planen.

Prüfkette:

Name korrekt?
  ↓
DNS korrekt?
  ↓
Route vorhanden?
  ↓
Port erreichbar?
  ↓
TLS gültig?
  ↓
Protokoll antwortet?
  ↓
Authentifizierung erfolgreich?
  ↓
Berechtigung ausreichend?
  ↓
Fachliche Anfrage erfolgreich?

[ ] Hauptdienst eindeutig bestimmt
[ ] Formale Betriebssystem-Abhängigkeiten erfasst
[ ] Vorwärts gerichtete Abhängigkeiten geprüft
[ ] Rückwärts gerichtete Abhängigkeiten geprüft
[ ] Startreihenfolge getrennt von Anforderung bewertet
[ ] Kritische und optionale Abhängigkeiten unterschieden
[ ] Externe Datenbanken erfasst
[ ] DNS- und Zeitabhängigkeiten erfasst
[ ] Authentifizierungsdienste erfasst
[ ] Speicher- und Dateisystemabhängigkeiten erfasst
[ ] Proxys, Loadbalancer und APIs erfasst
[ ] Container-, Cluster- oder Cloud-Abhängigkeiten berücksichtigt
[ ] DNS-Auflösung vom Dienstserver geprüft
[ ] Zielport vom Dienstserver geprüft
[ ] TLS und Zertifikatsname geprüft
[ ] Protokollspezifischer Funktionstest durchgeführt
[ ] Gemeinsame Abhängigkeiten anderer Störungen geprüft
[ ] Protokollzeitstempel korreliert
[ ] Auswirkungen eines Neustarts bewertet
[ ] Keine Geheimnisse dokumentiert
[ ] Nächsten Diagnoseschritt festgelegt

Eine Protokollmeldung kann sein:

• direkte Ursache,
• Folge einer anderen Störung,
• Warnung ohne Bezug zum aktuellen Problem,
• erwarteter Betriebszustand,
• Wiederholungsversuch,
• Ergebnis einer automatischen Wiederherstellung,
• Meldung eines vorgeschalteten oder abhängigen Systems.

Der erste sichtbare Fehler in einer Anwendung ist nicht zwingend das zeitlich erste technische Ereignis.

Folgende Zeitangaben müssen möglichst genau bestimmt werden:

Empfohlener Suchbereich:

Einige Minuten vor dem ersten sichtbaren Fehler
bis
einige Minuten nach dem letzten beobachteten Fehler

Prüffragen:

• Verwenden alle Systeme dieselbe Zeitzone?
• Protokolliert eine Anwendung in UTC?
• Sind die Systemuhren synchronisiert?
• Ist der Clientzeitstempel nur auf Sekunden genau?
• Gab es unmittelbar vorher einen Neustart oder eine Änderung?
• Ist das Problem dauerhaft oder nur kurzzeitig aufgetreten?

Ungeeignete Suche:

„Ich suche in allen Protokollen nach Fehlern.“

Geeignete Suche:

„Ich untersuche zwischen 09:10 und 09:20 Uhr die Ereignisse des Anwendungsdienstes, des Service Control Managers und der Datenbankverbindung.“

Eine gute Protokollsuche verwendet möglichst mehrere Filter:

• Zeitfenster,
• Server,
• Dienstname,
• Prozessname,
• Prozess-ID,
• Ereignisquelle,
• Ereignis-ID,
• Priorität,
• Transaktions- oder Korrelations-ID,
• Benutzer oder Sitzung,
• Zielserver,
• Fehlercode.

Empfohlene Reihenfolge:

1. Zeitpunkt festlegen
2. Hauptdienst filtern
3. Erste relevante Fehlermeldung bestimmen
4. Einige Ereignisse davor lesen
5. Abhängige Systeme prüfen
6. Fehlercode in offizieller Dokumentation nachschlagen
7. Ereignisse zeitlich zusammenführen
8. Hypothese mit einem gezielten Test überprüfen

Nicht jede Anwendung schreibt in das zentrale Betriebssystemprotokoll. Herstellerdokumentation und effektive Dienstkonfiguration müssen zusätzlich geprüft werden.

Alle registrierten Protokolle auflisten:

[RO] Get-WinEvent -ListLog *

Nur aktivierte Protokolle anzeigen:

[RO] Get-WinEvent -ListLog * |
    Where-Object IsEnabled |
    Select-Object LogName, RecordCount, FileSize, MaximumSizeInBytes |
    Sort-Object LogName

Bestimmtes Protokoll untersuchen:

[RO] Get-WinEvent -ListLog "System"

Registrierte Ereignisanbieter suchen:

[RO] Get-WinEvent -ListProvider "*<SUCHBEGRIFF>*"

Typische Windows-Protokolle:

Der Zugriff auf das Sicherheitsprotokoll und bestimmte administrative Protokolle erfordert erhöhte Berechtigungen.

Letzte 50 Systemereignisse anzeigen:

[RO] Get-WinEvent -LogName "System" -MaxEvents 50 |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Letzte 50 Anwendungsereignisse anzeigen:

[RO] Get-WinEvent -LogName "Application" -MaxEvents 50 |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Neueste Ereignisse zuerst tabellarisch anzeigen:

[RO] Get-WinEvent -LogName "System" -MaxEvents 100 |
    Format-Table TimeCreated,
                 Id,
                 LevelDisplayName,
                 ProviderName,
                 Message -Wrap

Format-Table sollte hauptsächlich für die Anzeige verwendet werden. Für Export oder Weiterverarbeitung bleiben die ursprünglichen Ereignisobjekte geeigneter.

Ereignisse der letzten Stunde:

[RO] $startTime = (Get-Date).AddHours(-1)

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

Festes Zeitfenster verwenden:

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

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

System- und Anwendungsprotokoll gemeinsam durchsuchen:

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

Die Uhrzeitangaben werden im Kontext des ausführenden Systems interpretiert. Zeitzone und Uhrzeitsynchronisation müssen deshalb vor der Korrelation geklärt sein.

Nach Ereignisanbieter filtern:

[RO] Get-WinEvent -FilterHashtable @{
    LogName      = "System"
    ProviderName = "Service Control Manager"
    StartTime    = (Get-Date).AddHours(-2)
}

Nach bestimmten Ereignis-IDs filtern:

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

Nur kritische Ereignisse und Fehler anzeigen:

[RO] Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    Level     = 1, 2
    StartTime = (Get-Date).AddHours(-2)
}

Übliche Windows-Ereignisebenen:

Ereignis-IDs sind nur zusammen mit Anbieter und Protokoll eindeutig zu bewerten. Dieselbe ID kann bei unterschiedlichen Anbietern eine andere Bedeutung besitzen.

Häufig relevante Ereignisse des Service Control Managers sind:

Wichtig:

• Die konkrete Nachricht muss immer mitgelesen werden.
• Die Bedeutung muss bei Bedarf anhand der Microsoft-Dokumentation und des betroffenen Produkts geprüft werden.
• Ein Service-Control-Manager-Ereignis kann nur die Auswirkung eines internen Anwendungsfehlers melden.
• Für die eigentliche Ursache muss häufig zusätzlich das Anwendungsprotokoll untersucht werden.

Nach einem Dienstnamen innerhalb eines begrenzten Zeitraums suchen:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = (Get-Date).AddHours(-2)
} |
    Where-Object Message -Match "<DIENSTNAME>" |
    Select-Object TimeCreated,
                  LogName,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message

Nach einem Fehlercode suchen:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = (Get-Date).AddHours(-24)
} |
    Where-Object Message -Match "<FEHLERCODE>"

Textfilter mit Where-Object werden erst nach dem Lesen der Ereignisse angewendet und können bei großen Protokollen langsam sein. Zeitfenster, Protokoll und Anbieter sollten deshalb bereits serverseitig mit FilterHashtable eingeschränkt werden.

Informationen zu einem Protokoll anzeigen:

[RO] wevtutil get-log "System"

Kurzform:

[RO] wevtutil gl "System"

Die letzten Ereignisse eines Protokolls abfragen:

[RO] wevtutil query-events "System" /count:20 /reverse-direction:true /format:text

Kurzform:

[RO] wevtutil qe "System" /c:20 /rd:true /f:text

Ein vollständiges Ereignisprotokoll exportieren:

[RO][FILE][SENS][PRIV] wevtutil export-log `
    "System" `
    "<AUSGABEDATEI>.evtx"

Kurzform:

[RO][FILE][SENS][PRIV] wevtutil epl "System" "<AUSGABEDATEI>.evtx"

Eine EVTX-Datei kann Benutzernamen, Rechnernamen, interne Pfade, IP-Adressen und sicherheitsrelevante Ereignisse enthalten. Sie darf nur kontrolliert weitergegeben werden.

Gesamtes Journal einer systemd-Unit anzeigen:

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

Neueste Einträge zuerst anzeigen:

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

Letzte 100 Einträge anzeigen:

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

Nur Ereignisse des aktuellen Systemstarts:

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

Ereignisse des vorherigen Systemstarts:

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

Ob Ereignisse früherer Systemstarts verfügbar sind, hängt von der Journal-Konfiguration und Aufbewahrung ab.

Ereignisse seit einer festen Uhrzeit:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "2026-07-31 09:10:00" \
  --no-pager

Festes Start- und Endzeitfenster:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "2026-07-31 09:10:00" \
  --until "2026-07-31 09:20:00" \
  --no-pager

Relative Zeitangabe:

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

Alle Ereignisse des heutigen Tages:

[RO][SENS][PRIV] sudo journalctl --since today --no-pager

Zeitstempel mit ISO-Datum ausgeben:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "1 hour ago" \
  --output=short-iso \
  --no-pager

Übliche syslog-Prioritäten:

Fehler und schwerwiegendere Meldungen eines Dienstes:

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

Warnungen und schwerwiegendere Meldungen:

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

Nur einen bestimmten Prioritätsbereich verwenden:

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

Nicht jede Anwendung verwendet Prioritäten korrekt. Eine relevante Fehlermeldung kann deshalb als info oder ohne geeignete Priorität protokolliert worden sein.

Nach Prozess-ID filtern:

[RO][SENS][PRIV] sudo journalctl _PID=<PID> --no-pager

Nach ausführbarer Datei filtern:

[RO][SENS][PRIV] sudo journalctl \
  _EXE="<VOLLSTÄNDIGER_PROGRAMMPFAD>" \
  --no-pager

Nach syslog-Kennung filtern:

[RO][SENS][PRIV] sudo journalctl \
  -t "<KENNUNG>" \
  --no-pager

Felder eines Ereignisses ausführlich anzeigen:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  -n 20 \
  -o verbose \
  --no-pager

Mögliche strukturierte Felder:

_SYSTEMD_UNIT
_PID
_UID
_GID
_EXE
_COMM
_HOSTNAME
SYSLOG_IDENTIFIER
PRIORITY
MESSAGE

PID-Filter sind nur für die Lebensdauer der jeweiligen Prozessinstanz geeignet. Nach einem Neustart besitzt der Dienst möglicherweise eine neue PID.

Kernelmeldungen des aktuellen Systemstarts:

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

Kernelwarnungen und schwerwiegendere Meldungen:

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

Alle Meldungen des aktuellen Systemstarts:

[RO][SENS][PRIV] sudo journalctl -b --no-pager

Verfügbare Systemstarts anzeigen:

[RO] journalctl --list-boots

Relevante Kernelhinweise können sein:

• Datenträger- und Dateisystemfehler,
• Netzwerkadapterfehler,
• Speichermangel,
• Prozessbeendigung durch den Out-of-Memory-Mechanismus,
• Treiberprobleme,
• schreibgeschützte Dateisysteme,
• blockierte Aufgaben,
• Hardwarefehler.

Neue Ereignisse eines Dienstes live anzeigen:

[TEST][SENS][PRIV] sudo journalctl \
  -f \
  -u "<DIENST>"

Mit bestehenden letzten Zeilen beginnen:

[TEST][SENS][PRIV] sudo journalctl \
  -n 50 \
  -f \
  -u "<DIENST>"

Nur Warnungen und schwerwiegendere Meldungen verfolgen:

[TEST][SENS][PRIV] sudo journalctl \
  -f \
  -u "<DIENST>" \
  -p warning

Vorgehen beim kontrollierten Live-Test:

1. Live-Ansicht starten
2. Genauen Startzeitpunkt notieren
3. Eine einzelne Testaktion ausführen
4. Neue Ereignisse beobachten
5. Testaktion und Ereignisse zeitlich zuordnen
6. Live-Ansicht mit Strg+C beenden
7. Relevante Meldungen dokumentieren

Live-Logging kann große Mengen ausgeben. Der Filter sollte vor dem Test möglichst eng gesetzt werden.

Belegten Speicherplatz des Journals anzeigen:

[RO] journalctl --disk-usage

Verfügbare Systemstarts anzeigen:

[RO] journalctl --list-boots

Journal-Konfiguration lesen:

[RO][FILE] systemd-analyze cat-config systemd/journald.conf

Wichtige Konfigurationsbereiche können sein:

Storage
SystemMaxUse
RuntimeMaxUse
MaxRetentionSec
MaxFileSec
RateLimitIntervalSec
RateLimitBurst

Mögliche Gründe für fehlende alte Einträge:

• Journal wird nur flüchtig gespeichert,
• Größenbegrenzung wurde erreicht,
• Aufbewahrungszeit ist abgelaufen,
• System wurde neu gestartet,
• Protokollrotation hat alte Daten entfernt,
• Rate-Limiting hat Meldungen unterdrückt,
• Anwendung schrieb in eine andere Datei,
• Dienst startete in einem Container mit eigener Protokollierung.

Aufbewahrungseinstellungen dürfen nicht während einer Störung ungeprüft verändert werden. Zuerst muss der aktuelle Zustand dokumentiert werden.

Der tatsächliche Protokollpfad muss aus Herstellerdokumentation oder effektiver Konfiguration ermittelt werden.

Letzte Zeilen einer bekannten Protokolldatei:

[RO][FILE][SENS][PRIV] sudo tail -n 100 "<PROTOKOLLDATEI>"

Neue Einträge live verfolgen:

[TEST][FILE][SENS][PRIV] sudo tail -F "<PROTOKOLLDATEI>"

Nach einem festen Text suchen:

[RO][FILE][SENS][PRIV] sudo grep \
  -n \
  -i \
  -- "<SUCHTEXT>" \
  "<PROTOKOLLDATEI>"

Komprimierte rotierte Protokolle durchsuchen:

[RO][FILE][SENS][PRIV] sudo zgrep \
  -n \
  -i \
  -- "<SUCHTEXT>" \
  "<PROTOKOLLDATEI>.gz"

Datei kontrolliert mit Pager öffnen:

[RO][FILE][SENS][PRIV] sudo less "<PROTOKOLLDATEI>"

Nützliche Tasten in less:

Keine angenommenen Standardpfade verwenden. Container, Pakete und Hersteller können unterschiedliche Protokollziele konfigurieren.

Meldungen der letzten Stunde anzeigen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --style compact \
  --no-pager

Meldungen seit dem letzten Systemstart:

[RO][SENS][PRIV] sudo log show \
  --last boot \
  --style compact \
  --no-pager

Festes Zeitfenster verwenden:

[RO][SENS][PRIV] sudo log show \
  --start "2026-07-31 09:10:00" \
  --end "2026-07-31 09:20:00" \
  --style compact \
  --no-pager

Lokale Zeitzone ausdrücklich verwenden:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --timezone local \
  --style compact \
  --no-pager

Standardmäßig zeigt log show nicht zwingend alle Info- und Debugmeldungen. Diese Ebenen werden bei Bedarf ausdrücklich aktiviert.

Nach Prozessnamen filtern:

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

Nach Prozess-ID filtern:

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

Info-Meldungen einschließen:

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

Info- und Debugmeldungen einschließen:

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

Die Erhöhung des sichtbaren Umfangs kann sehr große Ausgaben erzeugen. Zuerst sollte mit engem Zeitfenster und Prozessfilter gearbeitet werden.

Nach bekanntem Subsystem filtern:

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

Fehler und Faults eines Prozesses anzeigen:

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

Nach Text innerhalb der Meldung suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'eventMessage CONTAINS[c] "<SUCHTEXT>"' \
  --style compact \
  --no-pager

Wichtige Filterfelder:

Meldungen eines Prozesses live verfolgen:

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

Fehler und Faults live verfolgen:

[TEST][SENS][PRIV] sudo log stream \
  --predicate 'process == "<PROZESS>" AND (messageType == error OR messageType == fault)' \
  --style compact

Live-Ausgabe zeitlich begrenzen:

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

Info-Ebene einbeziehen:

[TEST][SENS][PRIV] sudo log stream \
  --level info \
  --predicate 'process == "<PROZESS>"' \
  --style compact

Der Befehl wird ohne Zeitbegrenzung mit Strg+C beendet. Eine zeitliche Begrenzung verhindert versehentlich lange laufende Mitschnitte.

Protokolle der letzten Stunde in ein Logarchiv sammeln:

[RO][FILE][SENS][PRIV] sudo log collect \
  --last 1h \
  --output "<AUSGABEDATEI>.logarchive"

Protokolle ab einem festen Zeitpunkt sammeln:

[RO][FILE][SENS][PRIV] sudo log collect \
  --start "2026-07-31 09:10:00" \
  --output "<AUSGABEDATEI>.logarchive"

Ein .logarchive kann später mit der App „Konsole“ oder mit log show ausgewertet werden.

Archiv über die Kommandozeile lesen:

[RO][FILE][SENS] log show \
  --archive "<AUSGABEDATEI>.logarchive" \
  --style compact \
  --no-pager

Ein vollständiges macOS-Logarchiv kann umfangreiche und sensible Systeminformationen enthalten. Vor einer externen Weitergabe müssen Zweck, Empfänger und Datenschutz geprüft werden.

Nicht jede Anwendung verwendet ausschließlich das zentrale Systemprotokoll.

Mögliche Protokollziele:

• Windows-Anwendungsprotokoll,
• eigenes Windows-Ereignisprotokoll,
• macOS Unified Logging,
• Textdatei,
• JSON-Datei,
• Datenbank,
• Container-Standardausgabe,
• zentraler Syslog-Server,
• SIEM- oder Monitoringplattform,
• herstellerspezifisches Diagnosepaket.

Protokollpfad korrekt ermitteln über:

1. Herstellerdokumentation,
2. wirksame Dienstkonfiguration,
3. Startparameter,
4. Umgebungsvariablen,
5. Dienstkonto,
6. Containerdefinition,
7. Protokollierungs- oder Loggingabschnitt der Anwendung.

Keine Verzeichnisse oder Dateinamen als gegeben annehmen. Der wirksame Pfad kann durch Installation, Paketierung oder lokale Konfiguration verändert worden sein.

Bei containerisierten Diensten können Protokolle an mehreren Stellen entstehen:

Hostbetriebssystem
  → Container-Runtime
  → Container
  → Prozess im Container
  → Anwendung
  → externes zentrales Logging

Mögliche Protokollquellen:

• Runtime-Ereignisse auf dem Host,
• Standardausgabe und Standardfehler des Containers,
• an ein Volume gebundene Anwendungsprotokolle,
• Reverse-Proxy-Protokolle,
• Datenbankprotokolle,
• Orchestrator-Ereignisse,
• Healthcheck-Ausgaben.

Prüffragen:

• Wurde der Container neu erstellt?
• Ist die Container-ID gewechselt?
• Wurden alte Containerprotokolle entfernt?
• Schreibt die Anwendung in die Standardausgabe oder in eine Datei?
• Ist das Logverzeichnis dauerhaft eingebunden?
• Gibt es Größenbegrenzung und Rotation?
• Werden Protokolle an einen zentralen Dienst weitergeleitet?
• Enthält die Ausgabe Secrets oder personenbezogene Daten?

Die konkrete Runtime wird in dieser Seite nicht vorausgesetzt. Die passenden Befehle müssen anhand der tatsächlich eingesetzten Containerplattform ausgewählt werden.

Beispiel:

Wahrscheinliche Ereigniskette:

Datenträgerfehler
  → Datenbankfehler
  → Verbindung des Anwendungsservers bricht ab
  → Webserver erhält keine gültige Backendantwort
  → Benutzer sieht HTTP 503

Vorgehen:

1. Alle Zeitstempel in dieselbe Zeitzone überführen.
2. Erstes technisches Ereignis bestimmen.
3. Vorhergehende Warnungen berücksichtigen.
4. Fehler auf Quell- und Zielsystem vergleichen.
5. Verbindungs- oder Korrelations-IDs verwenden.
6. Ursache und Folge in einer Zeitleiste dokumentieren.
7. Hypothese mit technischen Tests bestätigen.

Ein Fehlercode sollte zusammen mit folgendem Kontext dokumentiert werden:

Betriebssystem:
Produkt:
Komponente:
Version:
Protokoll:
Ereignisanbieter:
Ereignis-ID:
Fehlercode:
Vollständige Meldung:
Zeitpunkt:
Auslösende Aktion:

Regeln:

• Code vollständig übernehmen,
• hexadezimale und dezimale Schreibweise nicht verwechseln,
• Anbieter und Produktversion notieren,
• nur offizielle Herstellerdokumentation als gesicherte Bedeutung behandeln,
• nicht denselben Code aus einem anderen Produkt übertragen,
• innere oder verschachtelte Fehlermeldungen mit erfassen,
• Ursache erst nach Prüfung festlegen.

Eine Suchmaschinenfundstelle ohne passenden Hersteller-, Versions- und Komponentenkontext ist kein ausreichender Ursachenbeweis.

Keine gefundene Meldung bedeutet nicht automatisch, dass kein Fehler auftrat.

Mögliche Gründe:

• falsches Zeitfenster,
• falsche Zeitzone,
• falscher Server,
• falsches Protokoll,
• falscher Prozessname,
• Dienst wurde mit neuer PID gestartet,
• Protokollierung ist deaktiviert,
• Aufbewahrung ist abgelaufen,
• Logrotation hat die Datei verschoben,
• Rate-Limiting unterdrückte Meldungen,
• Anwendung schreibt in eine andere Datei,
• Meldung wurde nur auf dem Backend erzeugt,
• Debugebene war nicht aktiviert,
• Container wurde entfernt,
• Dienst stürzte vor Initialisierung der Protokollierung ab,
• Berechtigung zum Lesen fehlt.

Das Fehlen einer Meldung ist nur dann aussagekräftig, wenn bekannt ist, dass genau dieses Ereignis an dieser Stelle protokolliert werden müsste.

Protokolle können enthalten:

• Benutzernamen,
• E-Mail-Adressen,
• IP-Adressen,
• interne Servernamen,
• Dateipfade,
• Dokumentnamen,
• Datenbankabfragen,
• URL-Parameter,
• Sitzungscookies,
• Zugriffstoken,
• API-Schlüssel,
• Authorization-Header,
• personenbezogene Daten,
• interne Geschäfts- und Systeminformationen.

Vor Weitergabe prüfen:

[ ] Zweck der Weitergabe geklärt
[ ] Empfänger berechtigt
[ ] Zeitraum auf das Notwendige begrenzt
[ ] Nicht relevante Ereignisse entfernt
[ ] Kennwörter und Token entfernt
[ ] Cookies und Authorization-Header entfernt
[ ] Personenbezogene Daten geschützt
[ ] Interne Infrastrukturinformationen bewertet
[ ] Originaldatei beweissicher aufbewahrt
[ ] Bearbeitete Kopie als solche gekennzeichnet

Das Original darf bei einer Beweissicherung nicht unkontrolliert verändert werden. Für Weitergaben wird eine gesonderte bereinigte Kopie erstellt.

Dokumentationsvorlage:

Störung:
Server:
Dienst:
Betriebssystem:
Zeitzone:
Untersuchter Zeitraum:
Protokollquelle:
Ereignisanbieter beziehungsweise Prozess:
Ereignis-ID:
Fehlercode:
Zeitstempel:
Vollständige relevante Meldung:
Unmittelbar vorhergehendes Ereignis:
Unmittelbar folgendes Ereignis:
Betroffene Abhängigkeit:
Interpretation:
Beleg für die Interpretation:
Nächster Prüfschritt:

Gute Dokumentation:

Um 09:15:02 Uhr protokollierte der Anwendungsdienst eine zurückgesetzte Datenbankverbindung. Zwei Sekunden zuvor meldete der Datenbankserver einen Schreibfehler. Die zeitliche Reihenfolge spricht für einen Zusammenhang, der durch Datenträger- und Datenbankprüfung bestätigt werden muss.

Unzureichende Dokumentation:

In den Logs stand etwas mit Datenbank.

[ ] Störung und auslösende Aktion eindeutig beschrieben
[ ] Server und Dienst bestätigt
[ ] Beginn und Ende des Fehlers bestimmt
[ ] Zeitzonen aller beteiligten Systeme geprüft
[ ] Zeitfenster einige Minuten erweitert
[ ] Betriebssystemprotokoll geprüft
[ ] Dienst- beziehungsweise Anwendungsprotokoll geprüft
[ ] Ereignisanbieter oder Prozess gefiltert
[ ] Ereignis-ID und Fehlercode erfasst
[ ] Meldungen unmittelbar vor dem Fehler gelesen
[ ] Meldungen unmittelbar nach dem Fehler gelesen
[ ] Abhängige Systeme geprüft
[ ] Ursache und Folge getrennt
[ ] Prozessneustart und PID-Wechsel berücksichtigt
[ ] Protokollaufbewahrung und Rotation geprüft
[ ] Fehlende Meldungen nicht vorschnell bewertet
[ ] Relevante Protokolle gesichert
[ ] Sensible Inhalte vor Weitergabe entfernt
[ ] Hypothese durch einen technischen Test geprüft
[ ] Ergebnis und nächster Schritt dokumentiert

[ ] 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