systemd verstehen: So steuerst du Dienste auf modernen Linux-Servern

Im Alltag reichen start, stop, enable und status erstaunlich weit. Deshalb bleibt das Modell dahinter bei vielen Admins unscharf, bis ein Dienst nach dem Reboot nicht mehr hochkommt, ein Restart-Loop die Logs flutet oder eine Anwendung startet, bevor das Netzwerk oder das NFS-Mount bereit ist. Dann stellt sich heraus, dass systemd kein Ersatz für die alten Init-Skripte ist, sondern eine andere Denkweise: Statt einer festen Reihenfolge beschreibst du Abhängigkeiten und Zustände, und systemd entscheidet über die Parallelisierung.

Dazu kommt, dass systemd viel mehr ist als der Service-Manager. Ein Unit-Typ verwaltet Mounts, einer Sockets, einer Timer, einer Geräte, einer Ressourcengrenzen über cgroups. Wer nur .service kennt, baut Umwege: ein Cronjob statt eines Timers, ein Wrapper-Skript statt einer sauberen Dependency, ein selbst gebasteltes Logfile statt journald mit strukturierten Feldern. Das funktioniert eine Weile und fällt genau dann auf die Füße, wenn du unter Zeitdruck debuggen musst.

Typische Fehlerbilder wiederholen sich: Die Unit liegt im falschen Verzeichnis und wird von einem Paketupdate überschrieben, weil sie nicht als Drop-in unter /etc/systemd/system angelegt wurde. After= wird mit Requires= verwechselt, sodass die Reihenfolge stimmt, die Abhängigkeit aber fehlt oder umgekehrt. Der Type= passt nicht zum Verhalten des Prozesses, also gilt der Dienst als gestartet, obwohl er noch initialisiert. Und Restart=always verdeckt einen Konfigurationsfehler so lange, bis StartLimitBurst zuschlägt.