Kurzfassung: systemctl status zeigt den aktuellen Zustand und detaillierte Informationen zu Systemdiensten an, inklusive Status, PID, Ressourcennutzung und letzten Logs. Zielgruppe: Systemadministratoren zur Diagnose und Überwachung von Services.
Der Befehl systemctl status ist ein essentielles Diagnostik-Tool zur Überprüfung von Systemdiensten. Er liefert Informationen wie:
# Status eines Services abfragen systemctl status nginx # Status eines Services ohne Pagination systemctl status --no-pager nginx # Status ohne letzte Logs systemctl status --no-legend nginx
Die Ausgabe gliedert sich in folgende Bereiche:
Service-Identifikation:
● nginx.service - A high performance web server and a reverse proxy server
Zeigt Unit-Name (nginx.service) und Beschreibung.
Loaded-Zeile:
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
loaded: Unit-Datei gefunden und geparsedenabled: Service startet beim Bootpreset: Vordefinierte KonfigurationActive-Zeile:
Active: active (running) since Fri 2026-01-30 19:38:32 CET; 10min ago
active: Service läuft(running): Genauer Status-Typ# Zeigt PID und Prozessbaum systemctl status nginx | grep -A 20 "CGroup" # Nur Memory-Nutzung systemctl status nginx | grep Memory # Nur CPU-Zeit systemctl status nginx | grep CPU
Beispiel-Analyse:
Process: 4617 ExecStartPre=/usr/sbin/nginx -t -q (code=exited, status=0/SUCCESS)
Process: 4619 ExecStart=/usr/sbin/nginx -g daemon on (code=exited, status=0/SUCCESS)
Main PID: 4653 (nginx)
Tasks: 7 (limit: 9422)
Memory: 5.0M (peak: 11.3M)
CPU: 48ms
Active-Status:
# Nur Wort ("active" oder "inactive") systemctl is-active nginx # Mit aussagekräftigen Typen: # active (running) - Service läuft # active (exited) - Service beendet, aber erfolgreich # active (waiting) - Service wartet auf Events # inactive (dead) - Service läuft nicht # failed - Fehler beim Start # activating/deactivating - Übergang läuft
code=exited, status=0/SUCCESS → Erfolgreich beendet code=exited, status=1/FAILURE → Mit Fehler beendet code=signal, signal=15/TERM → Durch SIGTERM beendet code=signal, signal=9/KILL → Durch SIGKILL beendet
# Alle Unit-Eigenschaften anzeigen systemctl show nginx # Spezifische Eigenschaften systemctl show -p MainPID -p MemoryCurrent -p CPUUsageNSec nginx # Abhängigkeiten systemctl show -p Requires -p Requisite -p Wants nginx
# Status anzeigen, dann in Logs navigieren systemctl status nginx journalctl -u nginx -n 20 -e # Nur Fehler-Logs anzeigen journalctl -u nginx -p err # Logs seit letztem Systemd-Start journalctl -u nginx -b
# Status in JSON-Format systemctl show nginx --output=json # Mehrere Services gleichzeitig systemctl status nginx mysql postgresql # Status und Exit-Code für Scripting if systemctl is-active --quiet nginx; then echo "nginx läuft" else echo "nginx nicht aktiv" fi
# 1. Logs zur Fehlerursache prüfen journalctl -u nginx -b --priority=err # 2. Unit-Datei validieren systemctl cat nginx | systemd-analyze verify - # 3. Service zurücksetzen und erneut starten sudo systemctl reset-failed nginx sudo systemctl start nginx
# Aktivierungsstatus prüfen systemctl is-enabled nginx # Logs auf Boot-Fehler prüfen journalctl -u nginx -b | head -20 # Abhängigkeiten prüfen systemctl list-dependencies nginx
# Resource-Limits anzeigen systemctl show -p MemoryLimit -p CPUQuota nginx # Prozessbaum detailliert ps -ef | grep nginx # Top mit nur diesem Service top -p $(systemctl show -p MainPID --value nginx)
systemctl status ohne Weitergabe liefert visuell farbcodierte Ausgabe
- Für Scripting is-active, is-enabled verwenden (einfach parsbar)
- journalctl immer zur Detailanalyse kombinieren
- Exit-Codes (status=0) vs Signal-Codes (signal=15) unterscheiden
- Memory-Peak zeigt Spitzenlast, nicht aktuell verbrauchten RAM
status=0 bedeutet Erfolg, nicht Fehler!
- Nicht alle Status-Wechsel sind Fehler (normal: exited nach Start)
- High Memory = Peak, nicht aktueller Verbrauch
- Task-Limit nicht mit PID-Limit verwechseln
- failed bedeutet: reset-failed vor erneutem Start nötig