systemctl meistern: Grundlegende Befehle für die Linux-Diensteverwaltung

Wenn Sie Linux-Server betreiben, werden Sie ständig systemctl verwenden. Sie verwenden es, wenn Nginx nicht startet, wenn PostgreSQL nach einem Neustart hochkommen muss, wenn ein Deployment einen sauberen Neustart erfordert und wenn ein Dienst „fehlgeschlagen“ meldet, der eigentliche Fehler aber im Journal vergraben ist.

Der Befehl ist nicht schwer, aber er hat einige Unterscheidungen, die wichtig sind: Starten ist nicht dasselbe wie Aktivieren, Neuladen ist nicht dasselbe wie Neustarten und Deaktivieren ist nicht dasselbe wie Maskieren. Sobald diese klar sind, wird die Diensteverwaltung viel weniger mysteriös.

systemd und systemctl verstehen

systemd ist das Init-System und die Diensteverwaltung, die von vielen großen Linux-Distributionen verwendet wird, darunter gängige Debian-, Ubuntu-, Fedora- und RHEL-Familienversionen. Es initialisiert den Userspace und verwaltet Prozesse, Sitzungen, Timer, Sockets, Mounts und Dienste.

systemctl ist das primäre Befehlszeilentool zur Steuerung und Überprüfung des Zustands des systemd-Managers und seiner Komponenten (Units). Dienste, also die Programme, die im Hintergrund laufen (Daemons), werden als Service-Units verwaltet (normalerweise mit der Endung .service).

Schlüsselkonzepte: Units und Targets

Obwohl sich dieser Artikel auf Dienste konzentriert, denken Sie daran, dass systemctl verschiedene Units verwaltet:

Service-Units (.service): Zur Verwaltung von Hintergrundprozessen (z. B. nginx.service).
Target-Units (.target): Zum Gruppieren von Units, um einen bestimmten Systemzustand darzustellen (z. B. multi-user.target, das eine typische Serverumgebung repräsentiert).

Grundlegende Befehle zur Dienststeuerung (Laufzeitzustand)

Diese Befehle steuern direkt, ob ein Dienst in der aktiven Systemsitzung gerade läuft oder gestoppt ist.

1. Einen Dienst starten

Verwenden Sie den Befehl start, um einen Dienst sofort zu starten, unabhängig von seiner Konfiguration für den Systemstart.

sudo systemctl start <dienstname>.service
# Beispiel: Starten des Apache-Webservers
sudo systemctl start apache2.service

2. Einen Dienst stoppen

Verwenden Sie den Befehl stop, um einen laufenden Dienst ordnungsgemäß zu beenden.

sudo systemctl stop <dienstname>.service
# Beispiel: Stoppen des MySQL-Datenbankdienstes
sudo systemctl stop mariadb.service

3. Einen Dienst neu starten

Dies wird häufig nach Änderungen an Konfigurationsdateien verwendet. Es stoppt den Dienst und startet ihn dann sofort wieder.

sudo systemctl restart <dienstname>.service
# Beispiel: Neustart des SSH-Daemons
sudo systemctl restart sshd.service

4. Konfiguration neu laden

Viele Dienste unterstützen einen Reload-Vorgang, der neue Konfigurationsdateien anwendet, ohne bestehende Verbindungen zu unterbrechen oder den Prozess vollständig zu stoppen. Dies ist schneller und weniger störend als ein vollständiger Neustart.

sudo systemctl reload <dienstname>.service
# Beispiel: Neuladen der Nginx-Konfiguration
sudo systemctl reload nginx.service

Tipp: Überprüfen Sie immer die Dokumentation des Dienstes. Wenn ein Dienst reload nicht unterstützt, ist nach Konfigurationsänderungen restart erforderlich.

Grundlegende Befehle zur Dienstpersistenz (Startzustand)

Während das Starten eines Dienstes dafür sorgt, dass er jetzt läuft, steuert das Aktivieren oder Deaktivieren, ob er beim Systemstart automatisch gestartet wird.

1. Einen Dienst aktivieren

Um sicherzustellen, dass ein Dienst nach einem Neustart automatisch startet, müssen Sie ihn aktivieren. Dadurch werden die erforderlichen symbolischen Links in den systemd-Konfigurationsverzeichnissen (/etc/systemd/system/) erstellt.

sudo systemctl enable <dienstname>.service
# Beispiel: Aktivieren von PostgreSQL für den Start beim Booten
sudo systemctl enable postgresql.service

2. Einen Dienst deaktivieren

Um zu verhindern, dass ein Dienst beim Booten automatisch startet, müssen Sie ihn deaktivieren. Dies entfernt die durch den Befehl enable erstellten symbolischen Links.

sudo systemctl disable <dienstname>.service
# Beispiel: Deaktivieren des Bluetooth-Dienstes auf einem Server
sudo systemctl disable bluetooth.service

3. Einen Dienst maskieren

Das Maskieren einer Unit verhindert, dass sie manuell, automatisch oder über Abhängigkeiten gestartet wird. Verwenden Sie es, wenn „diesen nicht starten“ stärker sein muss als disable.

sudo systemctl mask <dienstname>.service

# Um die Maskierung rückgängig zu machen:
sudo systemctl unmask <dienstname>.service

Dienststatus und Informationen prüfen

Zu wissen, ob ein Dienst läuft und warum er möglicherweise fehlschlägt, ist für die Fehlerbehebung entscheidend.

1. Status prüfen

Der Befehl status liefert eine detaillierte, sofortige Momentaufnahme des Dienstes, einschließlich der Frage, ob er aktiv ist, geladen ist, seine Prozess-ID und aktuelle Logeinträge.

systemctl status <dienstname>.service
# Beispiel: Überprüfen des Firewall-Status
systemctl status firewalld.service

Interpretation der Ausgabe:

Achten Sie auf drei Schlüsselzeilen in der Ausgabe:

Loaded: Zeigt an, ob die Unit-Datei korrekt geladen wurde (z. B. loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)).
Active: Zeigt den aktuellen Laufzeitzustand an (z. B. active (running) oder failed).
CGroup: Zeigt die dem Dienst zugeordnete Prozessbaumstruktur an.

2. Startpersistenz abfragen

Sie können überprüfen, ob ein Dienst so konfiguriert ist, dass er automatisch startet, ohne die vollständige Statusausgabe zu prüfen:

systemctl is-enabled <dienstname>.service
# Ausgabe ist 'enabled', 'disabled' oder 'masked'

3. Logs mit journalctl anzeigen

Während status die letzten Zeilen der Ausgabe anzeigt, müssen Sie für eine eingehende Fehlersuche journalctl verwenden. Dieser Befehl fragt das systemd-Journal ab, das alle System- und Dienstlogs sammelt.

Um Logs speziell für einen Dienst anzuzeigen:

# Alle Logs für den Dienst seit dem letzten Neustart anzeigen
journalctl -u <dienstname>.service

# Logs in Echtzeit anzeigen (wie tail -f)
journalctl -u <dienstname>.service -f

# Logs seit gestern anzeigen
journalctl -u <dienstname>.service --since "yesterday"

Warnung: Wenn ein Dienst den Status failed anzeigt, ist journalctl -u <dienst> -r (umgekehrte Reihenfolge, neueste zuerst) oft der schnellste Weg, um die Fehlermeldung zu sehen, die den Fehler verursacht hat.

4. Überprüfen, ob ein Dienst in Skripten läuft

Für Shell-Skripte ist systemctl status zu ausführlich. Verwenden Sie die Abfragebefehle:

systemctl is-active --quiet nginx.service
echo $?

systemctl is-failed nginx.service
systemctl is-enabled nginx.service

is-active --quiet gibt einen nützlichen Exit-Status zurück, ohne die vollständige Statusseite zu drucken. Das macht es besser für Health Checks und Automatisierung.

if ! systemctl is-active --quiet nginx.service; then
    echo "nginx läuft nicht" >&2
    exit 1
fi

5. Units auflisten

Wenn Sie den genauen Dienstnamen nicht kennen, listen Sie Units auf:

systemctl list-units --type=service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service

list-units zeigt geladene Units und ihren aktuellen Laufzeitzustand an. list-unit-files zeigt Unit-Dateien und an, ob sie aktiviert, deaktiviert, statisch, maskiert oder generiert sind. Diese Unterscheidung erklärt, warum ein Dienst auf der Festplatte existieren kann, aber nicht in der aktiven Unit-Liste erscheint.

Systemzustand verwalten (Targets)

systemctl wird auch verwendet, um globale Systemzustände zu verwalten, hauptsächlich über Targets.

1. Aktuellen Systemzustand anzeigen

Um zu sehen, in welches Target das System derzeit gebootet ist (z. B. Serverumgebung oder grafischer Desktop):

systemctl get-default

2. Standard-Boot-Target ändern

Wenn Sie einen Server konfigurieren, der niemals eine GUI starten soll, können Sie das Standard-Target auf multi-user.target setzen:

sudo systemctl set-default multi-user.target

3. Neustarten und Herunterfahren

Während die Befehle reboot und shutdown immer noch funktionieren, bietet systemctl die native Methode zur Durchführung dieser Aktionen:

# System sofort neu starten
sudo systemctl reboot

# System anhalten (ausschalten)
sudo systemctl poweroff

systemd nach Unit-Änderungen neu laden

Wenn Sie eine Unit-Datei bearbeiten oder einen Drop-In unter /etc/systemd/system hinzufügen, liest systemd diese nicht automatisch neu. Führen Sie aus:

sudo systemctl daemon-reload

Starten Sie dann den betroffenen Dienst neu oder laden Sie ihn neu:

sudo systemctl restart myapp.service

Um die endgültige Unit nach dem Zusammenführen von Vendor-Dateien und Drop-Ins zu überprüfen:

systemctl cat myapp.service
systemctl show myapp.service -p FragmentPath -p DropInPaths

Dies ist eine der schnellsten Methoden, um Probleme wie „Ich habe die falsche Datei bearbeitet“ zu erkennen.

Ein echter Fehlerbehebungsablauf

Wenn ein Dienst nicht startet, gehen Sie in dieser Reihenfolge vor:

Status prüfen:

systemctl status myapp.service

Logs für diese Unit lesen:

journalctl -u myapp.service -r

Wenn Sie kürzlich die Dienstdatei bearbeitet haben, systemd neu laden:

sudo systemctl daemon-reload

Starten Sie ihn erneut und verfolgen Sie die Logs live:

sudo systemctl restart myapp.service
journalctl -u myapp.service -f

Wenn er sofort fehlschlägt, überprüfen Sie die Unit-Definition:

systemctl cat myapp.service
systemctl show myapp.service -p ExecStart -p User -p WorkingDirectory

Die meisten Fehler sind alltäglich: falscher Pfad in ExecStart, fehlende Umgebungsdatei, Berechtigungsproblem, falsches Arbeitsverzeichnis, Port bereits belegt oder ein Syntaxfehler in der Konfiguration der Anwendung selbst.

Starten, Aktivieren, Neustarten, Neuladen: Das mentale Modell

Diese vier Verben sind leicht zu verwechseln:

start ändert den aktuellen Laufzeitzustand.
enable ändert das Bootverhalten.
restart stoppt und startet den Prozess.
reload fordert den vorhandenen Prozess auf, die Konfiguration erneut zu lesen, sofern der Dienst dies unterstützt.

Zum Beispiel nach der Installation von Nginx:

sudo systemctl start nginx.service
sudo systemctl enable nginx.service

Der erste Befehl startet es jetzt. Der zweite Befehl sorgt dafür, dass es nach einem Neustart startet. Wenn Sie nur start ausführen, kann der Dienst nach dem nächsten Neustart verschwinden. Wenn Sie nur enable ausführen, wird er möglicherweise erst beim nächsten Neustart ausgeführt, es sei denn, die Unit hat ein spezielles Installationsverhalten.

Nach dem Bearbeiten einer Nginx-Konfiguration testen Sie zuerst die Anwendungskonfiguration und laden Sie dann neu:

sudo nginx -t
sudo systemctl reload nginx.service

Wenn die Anwendung kein Neuladen unterstützt, verwenden Sie einen Neustart und planen Sie die Unterbrechung ein:

sudo systemctl restart myapp.service

Sicherere Verwendung der Maskierung

Maskierung ist nützlich, kann aber die nächste Person verwirren, die versucht, den Dienst zu starten.

sudo systemctl mask bluetooth.service
systemctl is-enabled bluetooth.service

Der Dienst meldet masked. Um es rückgängig zu machen:

sudo systemctl unmask bluetooth.service

Verwenden Sie Maskierung für klare Konflikte, z. B. um zu verhindern, dass ein alter Dienst gestartet wird, nachdem Sie ihn durch einen neuen ersetzt haben. Für normales „Nicht beim Booten starten“-Verhalten verwenden Sie disable.

Units auf wartbare Weise bearbeiten

Wenn Sie einen gepackten Dienst ändern müssen, vermeiden Sie es, Dateien direkt unter /usr/lib/systemd/system oder /lib/systemd/system zu bearbeiten. Paket-Upgrades können diese Dateien ersetzen. Verwenden Sie einen Override:

sudo systemctl edit myapp.service

Dadurch wird ein Drop-In unter /etc/systemd/system/myapp.service.d/ erstellt. Zum Beispiel:

[Service]
Environment=APP_ENV=production
Restart=on-failure
RestartSec=5s

Wenden Sie es dann an:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

Wenn Sie später einen Override entfernen müssen, überprüfen Sie zuerst die Drop-Ins:

systemctl show myapp.service -p DropInPaths

Entfernen Sie dann die spezifische Drop-In-Datei und führen Sie daemon-reload aus. Dies hält lokale Änderungen sichtbar und erleichtert die Überprüfung.

Benutzerdienste

Nicht jeder Dienst ist ein Systemdienst. Desktop-Tools, Entwicklungs-Daemons und benutzerspezifische Hintergrundprozesse können unter dem Benutzer-Manager ausgeführt werden:

systemctl --user status pipewire.service
systemctl --user restart my-user-job.service

Benutzerdienste verwenden sudo nicht auf die gleiche Weise und leben in der systemd-Instanz des Benutzers. Wenn ein Befehl mit systemctl --user funktioniert, aber nicht mit einfachem systemctl, handelt es sich um eine Benutzer-Unit, nicht um eine System-Unit.

Für langlebige Benutzerdienste auf Servern kann das Login-/Sitzungsverhalten wichtig sein. Einige Distributionen erfordern Lingering, um die Dienste eines Benutzers nach dem Abmelden am Laufen zu halten:

loginctl enable-linger deploy

Verwenden Sie dies bewusst. Ein Benutzerdienst kann das richtige Werkzeug für die Entwicklung oder benutzerbezogene Automatisierung sein, aber Produktions-Daemons sind oft klarer als Systemdienste mit expliziten Benutzern und Berechtigungen.

Zusammenfassung der wesentlichen systemctl-Befehle

Aktion	Befehlssyntax	Zweck
Jetzt starten	`sudo systemctl start name.service`	Führt den Dienst sofort aus.
Jetzt stoppen	`sudo systemctl stop name.service`	Beendet den laufenden Dienst.
Neustarten	`sudo systemctl restart name.service`	Stoppt und startet den Dienst.
Neuladen	`sudo systemctl reload name.service`	Wendet Konfigurationsänderungen ohne vollständigen Neustart an, falls unterstützt.
Aktivieren	`sudo systemctl enable name.service`	Konfiguriert den Dienst für den Start beim Booten.
Deaktivieren	`sudo systemctl disable name.service`	Verhindert, dass der Dienst beim Booten startet.
Status	`systemctl status name.service`	Überprüft den Laufzeitzustand und aktuelle Logs.
Logs anzeigen	`journalctl -u name.service`	Greift auf den vollständigen systemd-Journalverlauf für den Dienst zu.

Diese Befehle decken die meisten täglichen Arbeiten mit Diensten ab. Start und Stop steuern den aktuellen Prozess. Aktivieren und Deaktivieren steuern das Bootverhalten. Status, is-active und journalctl sagen Ihnen, was passiert ist. daemon-reload hält systemd mit Unit-Datei-Änderungen synchron. Wenn Sie diese Rollen getrennt halten, wird systemctl zu einem praktischen Fehlerbehebungswerkzeug und nicht zu einem Befehl, den Sie aus alten Notizen kopieren.