systemd Dienste verwalten: systemctl, Units & journalctl

systemd-Dienste verwaltest du mit dem Befehl systemctl: systemctl start dienst startet einen Dienst sofort, systemctl enable --now dienst startet ihn und richtet zugleich den Autostart beim Booten ein, systemctl status dienst zeigt Zustand und die letzten Logzeilen. Eigene Dienste beschreibst du in Unit-Dateien unter /etc/systemd/system/, Logs liest du mit journalctl -u dienst. Nach jeder Änderung an einer Unit folgt systemctl daemon-reload.

systemd ist seit 2010 das init-System (der erste Prozess, der beim Start alle anderen Dienste hochfährt) nahezu jeder großen Linux-Distribution – Ubuntu, Debian, Fedora, RHEL, Arch, openSUSE. Es ersetzt das alte SysVinit und bündelt Dienststart, Logging und Ressourcensteuerung in einem Werkzeug. Dieser Leitfaden zeigt dir die Befehle für den Alltag, wie du eine eigene Unit baust, Logs auswertest und Dienste begrenzt und absicherst – auf dem Stand von 2026, inklusive der Optionen, die inzwischen veraltet sind.

Die wichtigsten systemctl-Befehle

Fast alles, was du im Alltag brauchst, läuft über systemctl. Ein Dienst (englisch service) ist dabei ein Programm, das im Hintergrund läuft – etwa ein Webserver oder eine Datenbank. Die zentralen Befehle:

Befehl	Wirkung
systemctl start nginx	Dienst sofort starten (gilt nur bis zum Neustart)
systemctl stop nginx	Dienst sofort beenden
systemctl restart nginx	Dienst neu starten
systemctl reload nginx	Konfiguration neu einlesen, ohne den Dienst zu unterbrechen
systemctl enable nginx	Autostart beim Booten einrichten
systemctl enable --now nginx	Autostart einrichten und sofort starten (ein Befehl statt zwei)
systemctl disable nginx	Autostart entfernen
systemctl status nginx	Zustand, Prozess-ID und die letzten Logzeilen anzeigen
systemctl is-enabled nginx	prüfen, ob der Autostart aktiv ist (gut für Skripte)

Der häufigste Anfängerfehler: start und enable verwechseln. start wirkt nur jetzt, nach dem nächsten Neustart ist der Dienst wieder aus. enable sorgt für den dauerhaften Autostart, startet den Dienst aber nicht von selbst. enable --now erledigt beides in einem Schritt. Befehle, die in das System eingreifen, brauchen Root-Rechte – stelle ihnen sudo voran.

Eine eigene Service-Unit anlegen

Eine Unit-Datei beschreibt deklarativ, wie ein Dienst gestartet wird, wovon er abhängt und wie er sich im Fehlerfall verhält. So legst du einen einfachen eigenen Dienst an:

1. Unit-Datei erstellen. Lege die Datei /etc/systemd/system/mein-dienst.service an:

   [Unit]
   Description=Mein Beispieldienst
   After=network.target
   
   [Service]
   ExecStart=/usr/local/bin/mein-programm
   Restart=on-failure
   RestartSec=5
   
   [Install]
   WantedBy=multi-user.target

   After=network.target sorgt dafür, dass der Dienst erst startet, wenn das Netzwerk bereit ist. Restart=on-failure startet ihn nach einem Absturz automatisch neu, RestartSec=5 wartet dazwischen fünf Sekunden.
2. systemd über die neue Datei informieren. Führe systemctl daemon-reload aus. Diesen Schritt brauchst du nach jedem Anlegen oder Ändern einer Unit-Datei – sonst arbeitet systemd weiter mit der alten Version.
3. Syntax prüfen. systemd-analyze verify /etc/systemd/system/mein-dienst.service meldet Tippfehler und unbekannte Optionen, bevor der Start scheitert.
4. Starten und Autostart aktivieren. systemctl enable --now mein-dienst.service startet den Dienst und richtet den Autostart ein.
5. Kontrollieren. systemctl status mein-dienst.service zeigt, ob er läuft (active (running)) oder mit einem Fehler beendet wurde.

Wichtig: Bearbeite niemals die mitgelieferten Unit-Dateien aus dem Paketverzeichnis (/usr/lib/systemd/system/) direkt – ein Update überschreibt deine Änderungen. Für Anpassungen an fremden Diensten nutzt du systemctl edit dienst. Das erzeugt eine Drop-in-Datei, die nur einzelne Werte der Original-Unit überschreibt und Updates übersteht.

Logs lesen mit journalctl

systemd schreibt seine Logs strukturiert ins journal – jeder Eintrag trägt neben dem Text auch Dienstname, Prozess-ID und Schweregrad. Ausgewertet wird das mit journalctl:

• journalctl -u mein-dienst.service – nur die Logs dieses einen Dienstes.
• journalctl -u mein-dienst.service -f – den Log live mitlaufen lassen (wie tail -f).
• journalctl -u mein-dienst.service -b – nur Einträge seit dem letzten Boot.
• journalctl -p err – nur Fehler und schlimmer (filtert nach Schweregrad).
• journalctl --since "2026-06-17 10:00" --until "2026-06-17 12:00" – ein Zeitfenster eingrenzen.

Standardmäßig speichern manche Distributionen das journal nur im Arbeitsspeicher – nach einem Neustart sind die Logs dann weg. Damit das journal Neustarts übersteht, setzt du in /etc/systemd/journald.conf die Zeile Storage=persistent und legst das Verzeichnis mit mkdir -p /var/log/journal an. Mit SystemMaxUse=500M begrenzt du gleichzeitig, wie viel Platz die Logs belegen dürfen.

Ressourcen begrenzen – und warum MemoryLimit veraltet ist

systemd kann den Verbrauch jedes Dienstes über Linux-Control-Groups (cgroups) deckeln, damit ein einzelner Dienst nicht den ganzen Server lahmlegt. Hier hat sich seit den älteren Anleitungen einiges geändert:

MemoryLimit= ist veraltet und sollte nicht mehr verwendet werden. Es gehörte zur alten cgroup-v1-Hierarchie, die in aktuellen Systemen abgelöst ist. Moderne Systeme nutzen stattdessen zwei getrennte Stellschrauben:

• MemoryHigh=512M – die empfohlene Hauptbremse. Überschreitet der Dienst diesen Wert, drosselt der Kernel ihn und gibt Speicher frei, beendet den Dienst aber nicht.
• MemoryMax=768M – die harte Obergrenze als letzte Verteidigungslinie. Wird sie überschritten, greift der OOM-Killer (Out-of-Memory) und beendet in der Regel den Dienst.

In der Praxis setzt du MemoryHigh= als Arbeitsgrenze und MemoryMax= etwas höher als Notbremse. Für CPU und Datenträger gibt es CPUQuota=50% (maximal eine halbe CPU-Kernzeit) und IOWeight= (relative Priorität beim Plattenzugriff). Die aktuelle Auslastung deiner Dienste siehst du live mit systemd-cgtop.

Setze Grenzen behutsam: Ein zu niedriges MemoryMax= lässt einen Dienst sofort vom OOM-Killer beenden. Beobachte mit systemd-cgtop, was der Dienst im Normalbetrieb wirklich braucht, und lege die Werte mit Puffer darüber.

Dienste absichern und den Boot analysieren

Ein moderner Vorteil von systemd ist das eingebaute Sandboxing – du kannst einem Dienst per Unit-Datei genau die Rechte entziehen, die er nicht braucht. Nützliche Härtungsoptionen für die [Service]-Sektion:

• ProtectSystem=strict – macht fast das gesamte Dateisystem nur lesbar.
• ProtectHome=yes – blendet die Home-Verzeichnisse für den Dienst aus.
• PrivateTmp=yes – gibt dem Dienst ein eigenes, isoliertes /tmp.
• NoNewPrivileges=yes – verhindert, dass der Dienst nachträglich mehr Rechte erlangt.

Wie gut ein Dienst abgesichert ist, bewertet systemd-analyze security mein-dienst.service mit einer Punkteskala. Den Boot-Vorgang selbst analysierst du mit systemd-analyze blame (listet Dienste nach Startdauer) und systemd-analyze plot > boot.svg (erzeugt ein Zeitdiagramm) – so findest du den Dienst, der den Systemstart ausbremst.

Sicherheitshinweis: Teste neue Unit-Dateien und Grenzwerte zuerst auf einem Test- oder eigenen Rechner, nicht direkt auf einem Produktivserver. Eine falsch gesetzte Abhängigkeit oder ein zu strenges Sandboxing kann verhindern, dass ein wichtiger Dienst startet.

Häufige Fragen

Was ist der Unterschied zwischen systemctl start und enable?

start startet einen Dienst nur jetzt; nach einem Neustart ist er wieder aus. enable richtet den Autostart beim Booten ein, startet ihn aber nicht sofort. systemctl enable –now erledigt beides in einem Befehl.

Warum sollte ich MemoryLimit nicht mehr verwenden?

MemoryLimit gehört zur veralteten cgroup-v1-Hierarchie und gilt als deprecated. Moderne Systeme nutzen MemoryHigh als weiche Bremse (drosselt) und MemoryMax als harte Obergrenze (OOM-Killer).

Wie sehe ich die Logs eines bestimmten Dienstes?

Mit journalctl -u dienst.service siehst du nur dessen Logs. Der Zusatz -f lässt sie live mitlaufen, -b zeigt nur Einträge seit dem letzten Boot.

Wann muss ich systemctl daemon-reload ausführen?

Nach jedem Anlegen oder Ändern einer Unit-Datei oder Drop-in-Datei. Sonst arbeitet systemd weiter mit der zwischengespeicherten alten Version und ignoriert deine Änderung.

Wie ändere ich einen vom System mitgelieferten Dienst sicher?

Nutze systemctl edit dienst statt die Originaldatei zu bearbeiten. Das erzeugt eine Drop-in-Datei, die nur einzelne Werte überschreibt und Paket-Updates unbeschadet übersteht.