4.2 Dienststatus und Startart prüfen

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