systemd verstehen: Dienste verwalten, Logs lesen und Timer einrichten

Wenn du einen modernen Linux-Server verwaltest, kommst du an systemd nicht vorbei. Es ist das erste Programm, das beim Start nach dem Kernel geladen wird (Prozess-ID 1), und steuert von dort aus, welche Dienste laufen, in welcher Reihenfolge sie starten und was passiert, wenn einer abstürzt. Trotz seiner zentralen Rolle bleibt systemd vielen ein Rätsel. Dieser Artikel macht Schluss damit und zeigt dir, wie du Dienste verwaltest, eigene anlegst, Logs liest und Aufgaben automatisch ausführen lässt.

Was systemd eigentlich ist

systemd ist ein sogenanntes Init-System und Service-Manager. Es löste auf den meisten Distributionen das ältere SysVinit ab und brachte einige entscheidende Vorteile mit: paralleles Starten von Diensten für schnelleres Booten, ein einheitliches Steuerungswerkzeug und ein zentrales Logging-System. Heute setzen Debian, Ubuntu, Fedora, Arch Linux und die meisten Server-Distributionen auf systemd.

Das Grundkonzept dreht sich um Units – das sind Konfigurationsobjekte für alles, was systemd verwaltet. Der häufigste Typ ist die Service-Unit (Endung .service), die einen laufenden Dienst beschreibt. Daneben gibt es Timer-Units für zeitgesteuerte Aufgaben, Socket-Units, Mount-Units und mehr. Diese Vereinheitlichung ist die eigentliche Stärke von systemd: Ob Webserver, Datenbank oder dein eigenes Skript – alles spricht dieselbe Sprache.

Dienste steuern mit systemctl

Das zentrale Werkzeug heißt systemctl. Mit ihm bringst du Dienste unter Kontrolle. Die wichtigsten Befehle solltest du im Schlaf beherrschen:

• sudo systemctl start nginx startet den Dienst sofort.
• sudo systemctl stop nginx hält ihn an.
• sudo systemctl restart nginx startet ihn neu, etwa nach einer Konfigurationsänderung.
• sudo systemctl reload nginx lädt die Konfiguration neu, ohne den Dienst komplett zu unterbrechen (sofern der Dienst das unterstützt).
• systemctl status nginx zeigt detailliert, ob der Dienst läuft, seit wann und mit welcher Prozess-ID.

Ein entscheidender Unterschied, den viele Einsteiger verwechseln: start aktiviert einen Dienst nur für die aktuelle Sitzung. Damit er auch nach einem Neustart automatisch hochfährt, brauchst du sudo systemctl enable nginx. Umgekehrt entfernt disable den Autostart. Häufig kombiniert man beides mit sudo systemctl enable --now nginx, was den Dienst sofort startet und gleichzeitig für künftige Neustarts vormerkt.

Überblick behalten

Auf einem Server laufen schnell Dutzende Dienste. Diese Befehle verschaffen dir Überblick: systemctl list-units --type=service zeigt alle aktiven Dienste, systemctl --failed filtert gezielt jene heraus, die fehlgeschlagen sind. Letzteres ist oft der erste Befehl bei der Fehlersuche – er beantwortet auf einen Blick, ob etwas Grundlegendes nicht läuft. Mit systemctl list-unit-files siehst du zusätzlich, welche Dienste für den Autostart aktiviert sind.

Einen eigenen Dienst anlegen

Die wahre Macht von systemd entfaltet sich, wenn du eigene Programme als Dienst einrichtest. Stell dir vor, du hast eine kleine Webanwendung oder ein langlaufendes Skript, das im Hintergrund laufen und nach einem Absturz automatisch neu starten soll. Dafür legst du eine eigene Service-Unit unter /etc/systemd/system/ an, etwa meineapp.service.

Eine solche Unit-Datei besteht aus drei Abschnitten. Im Block [Unit] beschreibst du den Dienst und legst Abhängigkeiten fest, etwa dass er erst nach dem Netzwerk starten soll. Im Block [Service] stehen die eigentlichen Anweisungen: ExecStart nennt den auszuführenden Befehl, User legt fest, unter welchem Benutzer er läuft, und Restart=always sorgt dafür, dass systemd den Dienst bei einem Absturz automatisch wieder hochfährt. Im Block [Install] definierst du mit WantedBy=multi-user.target, wann der Dienst beim Systemstart aktiviert wird.

Nach dem Anlegen oder Ändern einer Unit-Datei musst du systemd anweisen, die Konfiguration neu einzulesen: sudo systemctl daemon-reload. Danach kannst du deinen Dienst wie jeden anderen mit enable --now starten. So läuft dein Programm zuverlässig im Hintergrund, übersteht Neustarts und richtet sich nach einem Fehler selbst wieder auf – Funktionen, die du sonst mühsam selbst programmieren müsstest.

Logs lesen mit journalctl

systemd bringt sein eigenes Logging-System mit, das Journal. Statt verstreuter Textdateien sammelt es alle Logmeldungen zentral, und journalctl ist dein Fenster darauf. Diese Befehle helfen dir bei der täglichen Fehlersuche:

• journalctl -u nginx zeigt nur die Logs eines bestimmten Dienstes.
• journalctl -u nginx -f verfolgt die Logs live mit, während neue Einträge entstehen.
• journalctl -u nginx --since "today" grenzt nach Zeit ein, etwa „seit heute“ oder „seit 1 hour ago“.
• journalctl -p err filtert nach Schweregrad und zeigt nur Fehler und Schlimmeres.
• journalctl -b beschränkt sich auf den aktuellen Systemstart.

Damit das Journal nicht endlos wächst, kannst du seine Größe begrenzen. sudo journalctl --vacuum-time=14d löscht beispielsweise alle Einträge, die älter als 14 Tage sind. Auf Servern mit knappem Speicher ist diese Wartung wichtig, damit die Logs nicht die Festplatte füllen.

Timer: die moderne cron-Alternative

Wiederkehrende Aufgaben hat man jahrzehntelang mit cron geplant. systemd bietet mit Timer-Units eine modernere Alternative, die zwei klare Vorteile hat: Die Ausführung wird sauber im Journal protokolliert, und verpasste Läufe (etwa weil der Server zum geplanten Zeitpunkt ausgeschaltet war) können nachgeholt werden.

Ein Timer besteht immer aus zwei Dateien mit gleichem Namen: einer .service-Datei, die festlegt, was ausgeführt wird, und einer .timer-Datei, die bestimmt, wann. Im Timer steuerst du mit OnCalendar den Zeitplan – etwa OnCalendar=daily für täglich oder eine präzise Angabe wie OnCalendar=*-*-* 03:00:00 für drei Uhr morgens. Mit Persistent=true sorgst du dafür, dass ein verpasster Lauf beim nächsten Hochfahren nachgeholt wird.

Aktive Timer listest du mit systemctl list-timers auf. Diese Übersicht zeigt dir, wann jeder Timer das nächste Mal feuert und wann er zuletzt lief – ideal, um deine Automatisierungen im Blick zu behalten. In Kombination mit einem gut geschriebenen Skript wird daraus eine zuverlässige, unbeaufsichtigte Routine.

Ein praktisches Zusammenspiel

Stell dir ein nächtliches Backup vor: Du schreibst ein Bash-Skript, das deine Daten sichert, und richtest dafür eine Service-Unit plus Timer ein, der jeden Morgen um drei Uhr läuft. Schlägt das Backup fehl, findest du den Grund sofort über journalctl, und dank Persistent=true wird ein Lauf nachgeholt, falls der Server nachts aus war. Wie du das zugrunde liegende Skript robust gestaltest, erklärt unser Artikel über Bash-Skripte schreiben.

Wenn du diese Konzepte auf einem echten Server üben willst, ohne dein Produktivsystem zu gefährden, bietet sich ein günstiger Cloud-Server an. Unsere Anleitung zur Einrichtung eines Hetzner Cloud VPS bringt dich in wenigen Minuten zu einer Umgebung, in der du systemctl, journalctl und Timer gefahrlos ausprobieren kannst.

Fazit

systemd wirkt anfangs überwältigend, folgt aber einer klaren Logik: Alles ist eine Unit, alles wird über systemctl gesteuert, und alle Logs landen im Journal. Mit den Befehlen start, enable, status und journalctl -u deckst du bereits den größten Teil des Alltags ab. Wer zusätzlich eigene Dienste und Timer anlegt, gewinnt ein mächtiges Werkzeug, um Programme zuverlässig laufen zu lassen und Aufgaben zu automatisieren. Investiere die Zeit, systemd wirklich zu verstehen – es ist eine der lohnendsten Fähigkeiten in der Linux-Administration.