systemd: was es ist, wie es funktioniert und wie Sie Dienste unter Linux verwalten

systemd ist das Init-System und der Dienstmanager, der in den meisten modernen Linux-Distributionen verwendet wird: Debian, Ubuntu, Fedora, RHEL und deren Ableger. Nach dem Start übergibt der Kernel die Kontrolle an systemd als ersten Prozess mit PID 1, und von da an bringt es das Netzwerk hoch, hängt Festplatten ein, startet den Webserver, die Datenbank und alles Übrige. Kurz gesagt ist systemd der „Disponent“, der weiß, welche Dienste laufen sollen, in welcher Reihenfolge sie starten und was bei einem Absturz zu tun ist.

Um zu prüfen, ob Sie systemd verwenden, genügt:

$ ps -p 1 -o comm=
systemd

Warum systemd entstanden ist

Früher nutzte Linux SysV init: eine Reihe von Shell-Skripten in /etc/init.d/, die nacheinander liefen. Das Schema war verständlich, aber langsam und anfällig. Jedes Skript schrieb seine eigene PID-Datei, entschied selbst, wie es prüft, ob ein Prozess lebt, und einen abgestürzten Dienst neu zu starten musste man separat nachrüsten.

systemd löst diese Aufgaben zentral:

• Paralleler Start. Dienste starten gleichzeitig, wenn zwischen ihnen keine Abhängigkeiten bestehen; so ist der Systemstart schneller.
• Abhängigkeiten und Reihenfolge. In der Dienstbeschreibung steht ausdrücklich, was der Dienst braucht (etwa das Netzwerk) und wonach er starten soll.
• Überwachung. systemd kennt alle Prozesse eines Dienstes über cgroups und kann ihn nach einem Fehler neu starten.
• Ein gemeinsames Journal. Die Ausgabe aller Dienste sammelt journald, Protokolle lesen Sie mit einem Befehl.
• Eine einheitliche Schnittstelle. Jeder Dienst wird gleich verwaltet: systemctl start|stop|restart|status.

Neben dem Dienstmanager umfasst das Projekt systemd mehrere Komponenten: journald (Protokollierung), logind (Benutzersitzungen), timesyncd (Zeitsynchronisation), resolved (DNS), networkd (Netzwerk). Nicht jede Distribution nutzt alle, doch systemd als PID 1 und journald gibt es fast überall.

Units: aus welchen Teilen systemd besteht

Alles, was systemd verwaltet, beschreiben Units. Eine Unit ist eine Textdatei im INI-Format; ihr Typ ergibt sich aus der Endung.

Wo die Unit-Dateien liegen

Unit-Dateien werden in mehreren Verzeichnissen abgelegt, und es gilt eine Rangfolge:

• /usr/lib/systemd/system/ (in Debian und Ubuntu auch /lib/systemd/system/) — durch Pakete installierte Units. Von Hand bearbeitet man sie nicht: Ein Paket-Update überschreibt Ihre Änderungen.
• /etc/systemd/system/ — Units und Anpassungen des Administrators. Sie haben die höchste Priorität.
• /run/systemd/system/ — temporäre Units, die während des Betriebs entstehen.

Den tatsächlichen Inhalt einer Unit samt allen Anpassungen zeigt systemctl cat nginx.service.

Targets statt Runlevels

Die alten Runlevels wurden durch Targets ersetzt. multi-user.target ist der übliche Servermodus ohne Grafik, graphical.target mit grafischer Oberfläche, rescue.target der Einzelbenutzer-Wiederherstellungsmodus. Das Standard-Target zeigt systemctl get-default, geändert wird es mit systemctl set-default multi-user.target.

systemctl: Dienste verwalten

systemctl ist das wichtigste Werkzeug für systemd. Die meisten Befehle ändern den Systemzustand und erfordern sudo.

So lesen Sie systemctl status

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-10-12 09:14:03 UTC; 2h 5min ago
       Docs: man:nginx(8)
   Main PID: 812 (nginx)
      Tasks: 3 (limit: 2307)
     Memory: 6.1M
        CPU: 154ms
     CGroup: /system.slice/nginx.service
             ├─812 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─813 "nginx: worker process"
             └─814 "nginx: worker process"

Die Zeile Loaded zeigt, woher die Unit-Datei stammt und ob der Autostart aktiv ist (enabled). Die Zeile Active ist der aktuelle Zustand: active (running), inactive (dead) oder failed. Im Block CGroup sehen Sie alle Prozesse des Dienstes — so erkennt systemd, was zu ihm gehört.

enable oder start

Das ist eine häufige Verwechslung. start startet den Dienst sofort, aber nach einem Neustart läuft er nicht von selbst. enable legt einen symbolischen Link im Verzeichnis des Targets an (zum Beispiel /etc/systemd/system/multi-user.target.wants/), dadurch startet der Dienst beim Booten, läuft jetzt aber nicht. Meist braucht man beides — verwenden Sie enable --now.

Es gibt noch einen dritten Zustand — mask. systemctl mask dienst verknüpft die Unit mit /dev/null, und sie lässt sich weder von Hand noch als Abhängigkeit starten. Das ist nützlich, wenn ein Dienst zuverlässig abgeschaltet werden soll.

journalctl: Dienst-Protokolle

Alles, was ein Dienst auf stdout und stderr schreibt, fängt systemd-journald ab und speichert es zusammen mit Metadaten — Unit-Name, PID, Priorität, Zeit — in einem binären Journal. Gelesen wird es mit dem Befehl journalctl.

journalctl -u nginx              # Protokoll eines Dienstes
journalctl -u nginx -f           # live verfolgen, wie tail -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -n 50        # die letzten 50 Zeilen
journalctl -b                    # seit dem aktuellen Systemstart
journalctl -b -1                 # der vorherige Systemstart
journalctl -p err -b             # nur Fehler und schwerwiegendere
journalctl -k                    # Kernel-Meldungen
journalctl --disk-usage          # wie viel Platz das Journal belegt

Die Option -p filtert nach syslog-Priorität: emerg, alert, crit, err, warning, notice, info, debug. Die gewählte Stufe umfasst alles, was schwerwiegender ist.

Das Journal nach einem Neustart

Existiert das Verzeichnis /var/log/journal nicht und steht in /etc/systemd/journald.conf Storage=auto, wird das Journal nur im Speicher (/run/log/journal) gehalten und geht beim Neustart verloren. Um es dauerhaft zu machen, setzen Sie Storage=persistent oder legen das Verzeichnis an und starten journald neu. Die Größe begrenzt der Parameter SystemMaxUse=, alte Einträge entfernen Sie mit journalctl --vacuum-time=2weeks oder --vacuum-size=500M.

journald arbeitet oft mit rsyslog zusammen: Das Journal leitet Meldungen an rsyslog weiter, das klassische Textdateien in /var/log/ schreibt und Logs an einen zentralen Server senden kann.

Autostart eines eigenen Dienstes: Beispiel einer Unit-Datei

Angenommen, Sie haben eine Anwendung — ein Skript oder ein Binärprogramm —, die dauerhaft laufen, beim Systemstart hochkommen und nach einem Absturz neu starten soll. Legen Sie die Datei /etc/systemd/system/myapp.service an:

[Unit]
Description=Meine Webanwendung
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/opt/myapp/bin/server --port 8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Schauen wir uns die Abschnitte an:

• [Unit] — Beschreibung und Abhängigkeiten. After= legt nur die Reihenfolge fest, Wants= ist eine weiche Abhängigkeit (die Unit wird hochgezogen, aber der Start scheitert nicht, wenn sie nicht hochkommt). Eine harte Abhängigkeit ist Requires=.
• [Service] — wie gestartet wird. Type=simple bedeutet, dass der Prozess aus ExecStart der Dienst selbst ist und nicht in den Hintergrund geht. User= startet ihn als unprivilegierten Benutzer. Restart=on-failure startet den Dienst neu, wenn er mit einem Fehler beendet wurde, nach RestartSec Sekunden.
• [Install] — was enable bewirkt. WantedBy=multi-user.target bedeutet „beim normalen Start mitstarten“.

Anwenden:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
journalctl -u myapp -f

Häufige Fehler in Unit-Dateien

• Relativer Pfad in ExecStart. Der Pfad zum Programm muss absolut sein. systemd sucht Befehle nicht im PATH des Benutzers, wie es eine Shell tut.
• daemon-reload vergessen. Nach einer Änderung arbeitet systemd mit der alten Version weiter und warnt davor in status.
• Der Dienst geht in den Hintergrund. Forkt sich das Programm selbst, steht aber Type=simple drin, hält systemd den Dienst für beendet. Entweder lassen Sie das Programm im Vordergrund laufen oder Sie verwenden Type=forking mit PIDFile=.
• Umgebungsvariablen aus dem Profil. Der Dienst sieht ~/.bashrc und /etc/profile nicht. Variablen setzt man mit Environment= oder EnvironmentFile=.

Anpassen ohne Änderung der Paket-Unit

Um Parameter eines Paket-Dienstes zu ändern, ohne seine Datei anzufassen, verwenden Sie ein Drop-in:

sudo systemctl edit nginx

Es öffnet sich ein Editor, und die Änderungen werden in /etc/systemd/system/nginx.service.d/override.conf gespeichert. Dort können Sie zum Beispiel einen Abschnitt [Service] mit Restart=always ergänzen. Nach dem Schließen des Editors liest systemd die Konfiguration selbstständig neu ein.

systemd-Timer statt cron

Ein Timer ist eine Unit, die einen gleichnamigen Dienst nach Zeitplan startet. Gegenüber cron hat er Vorteile: Die Logs der Aufgabe landen im Journal, Abhängigkeiten werden unterstützt, verpasste Läufe lassen sich nachholen (Persistent=true). Beispiel — ein nächtliches Backup:

# /etc/systemd/system/backup.service
[Unit]
Description=Nächtliches Backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Backup täglich ausführen

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers

Einen OnCalendar-Ausdruck prüfen Sie mit systemd-analyze calendar "*-*-* 03:00:00" — der Befehl zeigt, wann der nächste Lauf stattfindet.

Diagnose der Startzeit

systemd speichert die Startzeit jeder Unit, deshalb lässt sich ein langsamer Start leicht analysieren:

systemd-analyze                  # gesamte Startzeit
systemd-analyze blame            # Units, sortiert nach Startzeit
systemd-analyze critical-chain   # die Kette, die den Start verzögert hat
systemd-analyze verify /etc/systemd/system/myapp.service   # Unit-Datei prüfen

Fazit

systemd ist PID 1 und der Dienstmanager des modernen Linux. Es beschreibt alles mit Units, wird über systemctl gesteuert, sammelt Protokolle in einem Journal, das journalctl liest, und kann Aufgaben statt mit cron mit Timern starten. Um es sicher zu nutzen, sollten Sie status, enable --now, journalctl -u beherrschen und eine einfache Unit-Datei mit Restart=on-failure schreiben können. systemd, journald und Protokollierung behandelt unser Linux-Kurs praxisnah.