systemctl: Linux-Dienste auflisten — alle Wege

Der eine Befehl, den man kennen muss: systemctl list-units --type=service

Auf jeder Distribution mit systemd — Ubuntu seit 15.04, Debian seit 8, RHEL und CentOS seit 7, dazu Fedora, Arch und openSUSE — ist jeder Dienst eine systemd-Unit, und systemctl ist das Werkzeug, das sie auflistet:

systemctl list-units --type=service

Standardmäßig zeigt das jede Service-Unit, die systemd aktuell im Speicher hält: Dienste, die aktiv sind, die Jobs in der Warteschlange haben oder die fehlgeschlagen sind. Es zeigt nicht die Dienste, die installiert, aber nie gestartet wurden. Ist die Ausgabe länger als Ihr Terminal, leitet systemctl sie in einen Pager (less) — mit q beenden, oder --no-pager anhängen, um direkt nach stdout zu schreiben.

Jede Zeile hat fünf Spalten:

• UNIT — der Unit-Name, zum Beispiel ssh.service. Genau diesen Namen übergeben Sie an systemctl status, start und stop.
• LOAD — ob die Unit-Datei korrekt eingelesen wurde: loaded, not-found, bad-setting, error oder masked.
• ACTIVE — der übergeordnete Zustand: active, inactive, activating, deactivating oder failed.
• SUB — der Detailzustand, spezifisch für den Unit-Typ: ein Dienst kann running, exited, dead und so weiter sein.
• DESCRIPTION — der lesbare Text aus der Unit-Datei.

Lesen Sie das Paar ACTIVE/SUB immer zusammen: active (running) bedeutet, dass gerade ein Prozess läuft, während active (exited) bedeutet, dass ein Oneshot-Dienst erfolgreich durchgelaufen und beendet ist — normal für Einrichtungsaufgaben und kein Fehler, den man beheben muss.

Filtern: laufend, fehlgeschlagen oder alles

Die Option --state= filtert nach jedem LOAD-, ACTIVE- oder SUB-Wert und akzeptiert kommagetrennte Listen:

# Only services with a live process
systemctl list-units --type=service --state=running

# Everything loaded, including stopped and dead services
systemctl list-units --type=service --all

# Only failures
systemctl list-units --type=service --state=failed

# Combine states
systemctl list-units --type=service --state=running,exited

systemctl --failed ist die eingebaute Kurzform für den Failed-Filter und lohnt sich als Reflex auf jedem Server, auf dem Sie sich anmelden. Für maschinenlesbare Ausgabe entfernt --no-legend die Kopf- und Zusammenfassungszeilen und --plain die Aufzählungszeichen, damit die Spalten für awk oder cut stabil bleiben. Um nach Namen zu suchen, leiten Sie an grep weiter: systemctl list-units --type=service --all --no-pager | grep ssh.

Was beim Systemstart startet: systemctl list-unit-files

list-units beantwortet die Frage „was läuft jetzt?“. Um „was startet beim Booten?“ zu beantworten, listen Sie stattdessen die auf der Platte installierten Unit-Dateien auf:

systemctl list-unit-files --type=service
systemctl list-unit-files --type=service --state=enabled

Hier beschreibt die Spalte STATE die Boot-Konfiguration, nicht den Laufzeitzustand:

• enabled — startet automatisch beim Booten (oder bei seinem Trigger, bei socket- oder timer-aktivierten Diensten).
• disabled — installiert, aber nichts startet ihn automatisch.
• static — hat keinen [Install]-Abschnitt; läuft nur als Abhängigkeit einer anderen Unit und kann nicht direkt aktiviert werden.
• masked — per Symlink auf /dev/null gelegt; systemd verweigert den Start vollständig.
• generated — zur Laufzeit von einem Generator erzeugt, typischerweise aus einem alten Init-Skript.

Neuere systemd-Versionen zeigen zusätzlich eine Preset-Spalte (VENDOR PRESET oder PRESET, je nach Version), die den Standard der Distribution angibt. Die Falle, die Sie vermeiden sollten: enabled bedeutet nicht laufend, und disabled bedeutet nicht gestoppt. Ein Dienst kann deaktiviert und trotzdem laufen, weil jemand ihn manuell gestartet hat, oder aktiviert und trotzdem tot, weil er abgestürzt ist. Wenn es darauf ankommt, prüfen Sie beide Auflistungen gegen.

Ein Dienst auf einmal: status, is-active, is-enabled

Sobald ein Dienst Ihre Aufmerksamkeit erregt, gehen Sie ins Detail:

systemctl status nginx
systemctl is-active nginx    # prints: active | inactive | failed
systemctl is-enabled nginx   # prints: enabled | disabled | static | masked
systemctl is-failed nginx

status zeigt das ganze Bild: ACTIVE/SUB-Zustand, Haupt-PID, Laufzeit, Speicherverbrauch, den cgroup-Prozessbaum und die letzten zehn Journal-Zeilen. Wenn zehn Zeilen nicht genügen, gehen Sie direkt ins Journal mit journalctl -xeu nginx (-u filtert nach Unit, -e springt ans Ende, -x ergänzt erklärende Hinweise).

Die is-*-Befehle sind für Skripte gemacht: Sie geben ein einzelnes Wort aus und setzen den Exit-Code entsprechend — is-active endet nur mit 0, wenn die Unit aktiv ist, und is-enabled endet bei deaktivierten oder maskierten Units mit einem Wert ungleich 0. Mit --quiet unterdrücken Sie die Ausgabe und behalten nur den Exit-Code.

Alle oben genannten Auflistungsbefehle funktionieren als unprivilegierter Benutzer. Dienste tatsächlich zu verwalten — start, stop, enable, disable — erfordert root. Sie sollten also verstehen, wie sudo und Benutzerwechsel unter Ubuntu funktionieren, bevor Sie mehr tun als Zustände lesen. Beachten Sie auch, dass Units auf Benutzerebene in einem separaten Manager leben: systemctl --user list-units --type=service listet die Dienste Ihrer eigenen Sitzung auf — deshalb wirken manche Dienste in der Systemauflistung „verschwunden“.

Cheat Sheet: die Auflistungen, die Sie wirklich brauchen

Praxis-Workflows

1. Den Dienst finden, der immer wieder fehlschlägt

systemctl --failed
systemctl status myapp.service --no-pager -l
journalctl -xeu myapp.service
systemctl reset-failed myapp.service

Fangen Sie breit mit --failed an, lesen Sie dann die Status-Ausgabe für den Exit-Code und die letzten Log-Zeilen, und graben Sie anschließend im Journal nach dem vollständigen Trace. Ist die Ursache behoben und der Dienst wieder oben, löscht reset-failed den veralteten Failed-Eintrag, damit Ihr nächster Gesundheitscheck sauber startet.

2. Prüfen, was beim nächsten Booten startet

systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
systemd-analyze blame

Der erste Befehl liefert eine saubere Liste von allem, was automatisch startet — nützlich vor dem Härten eines Servers oder auf der Suche nach etwas, das Sie vor Monaten installiert und vergessen haben. systemd-analyze blame zeigt dann, wie lange jede Unit beim letzten Boot gebraucht hat — dort fallen langsam startende Dienste sofort auf.

3. Einzeiler für Skripte und Monitoring

systemctl is-active --quiet nginx && echo up || echo down
systemctl list-units --type=service --state=running --no-legend --plain | awk '{print $1}'
systemctl show -p ActiveState,SubState nginx
systemctl list-units --type=service -o json   # systemd 246 or newer

show -p gibt Key=Value-Paare aus, deren Format sich zwischen Versionen nie ändert, und die JSON-Ausgabe läuft direkt in jq. Wenn Sie dieselben Prüfungen bei jedem Login wiederholen, verpacken Sie sie in ein kleines Skript — unser Leitfaden zu .sh-Dateien und Shell-Skripting zeigt, wie aus genau solchen Snippets ein wiederverwendbares Werkzeug wird.

Kein systemd? service --status-all und OpenRC

Bevor Sie annehmen, dass systemctl existiert, prüfen Sie, was die Maschine tatsächlich betreibt — Betriebssystem und Version auf der Kommandozeile ermitteln dauert zehn Sekunden und verrät Ihnen, ob Sie überhaupt auf einer systemd-Distribution sind. Fehlt systemctl, sind Sie auf SysV-Init oder OpenRC:

service --status-all

Unter Debian und Ubuntu durchläuft das /etc/init.d und gibt [ + ] für laufend, [ - ] für gestoppt und [ ? ] für Skripte ohne Status-Befehl aus. Es funktioniert über eine Kompatibilitätsschicht auch auf systemd-Distributionen, sieht dort aber nur Init-Skripte — bevorzugen Sie also systemctl. Unter Alpine und Gentoo ist OpenRC das Init-System: rc-status listet die Dienste des aktuellen Runlevels und rc-update show zeigt, was jedes Runlevel startet.

Alles oben Genannte setzt voraus, dass Sie eine Linux-Maschine haben, auf der Sie root sind und Dienste frei starten, kaputt machen und reparieren können. Wenn Sie eine zum Üben brauchen — oder eine frische Maschine für echte Workloads — kommt ein Linux-VPS mit vollem Root-Zugriff von rdp.monster mit dedizierter CPU und RAM, unbegrenzter Bandbreite (Fair Use), ohne KYC, und wird etwa 10 Sekunden nach Zahlungsbestätigung bereitgestellt — Sie können also innerhalb einer Minute systemctl list-units auf Ihrem eigenen Server ausführen.

Häufig gestellte Fragen

Warum zeigt ein Dienst active (exited) statt active (running)?

Es ist ein Oneshot-Dienst, der erfolgreich durchgelaufen und beendet ist — kein Fehler.

Dienste mit Type=oneshot (oder RemainAfterExit=yes) führen eine Aufgabe einmal aus — Mounten, Firewall-Einrichtung, Aufräumen — und beenden sich. systemd meldet dann active (exited): die Unit war erfolgreich und gilt als „an“, aber es bleibt kein Prozess zurück. Nur Daemons wie nginx oder sshd zeigen active (running). Zeigt ein Dienst, den Sie als Daemon erwarten, exited, prüfen Sie seine Unit-Datei mit systemctl cat name.service, um zu sehen, wie er deklariert ist.

Was bedeuten die farbigen Punkte in der systemctl-Ausgabe?

Grün bedeutet aktiv, weiß inaktiv und rot fehlgeschlagen oder fehlerhaft.

Der Punkt vor einem Unit-Namen in systemctl status und systemctl list-units ist ein schneller Zustandsanzeiger: grün für aktiv, weiß für inaktiv oder deaktivierend und rot für fehlgeschlagene oder fehlerhafte Zustände. Fehlgeschlagene Zeilen werden in Auflistungen ebenfalls rot hervorgehoben, was systemctl --failed leicht überschaubar macht. In Skripten oder Logs, in denen Farbcodes stören, fügen Sie --plain hinzu oder leiten die Ausgabe weiter — dann verschwindet die Dekoration.

Gibt es ein systemctl-Äquivalent zu chkconfig --list?

Ja — systemctl list-unit-files --type=service ersetzt chkconfig --list.

Auf RHEL und CentOS 7 oder neuer wird chkconfig --list durch systemctl list-unit-files --type=service ersetzt, das jeden installierten Dienst zeigt und ob er enabled, disabled, static oder masked ist. Für einen einzelnen Dienst ersetzt systemctl is-enabled name das alte chkconfig name, und systemctl enable name ersetzt chkconfig name on. Der alte Befehl existiert möglicherweise noch als Kompatibilitätsschicht, deckt aber nur ältere SysV-Skripte ab.

Wie verhindere ich, dass ein Dienst beim Booten startet?

Mit systemctl disable aus dem Bootvorgang entfernen oder mit mask ganz blockieren.

Führen Sie sudo systemctl disable name aus, um den Boot-Symlink zu entfernen; mit --now wird der Dienst zugleich sofort gestoppt. Ein deaktivierter Dienst kann weiterhin manuell gestartet oder als Abhängigkeit einer anderen Unit mitgezogen werden. Soll er nie starten, verwenden Sie sudo systemctl mask name, was die Unit auf /dev/null verlinkt, sodass jeder Startversuch fehlschlägt. Später mit systemctl unmask zurücknehmen. Prüfen Sie das Ergebnis mit systemctl is-enabled name.