systemd: Architektur, Komponenten und Konfiguration

systemd ist nicht ein Programm, sondern eine Familie von rund neunzig Binaries um einen gemeinsamen Kern: einen Prozess-Manager als PID 1, der jeden Dienst in eine eigene cgroup sperrt, Abhängigkeiten als Transaktion auflöst und alles Weitere über D-Bus delegiert. Dieser Artikel zeigt, wer zu dieser Familie gehört, was jedes Mitglied tut und welche Datei man anfasst, um es zu ändern.

1. Vier Ideen, aus denen alles Weitere folgt

Fast jede Eigenart von systemd lässt sich auf eine dieser vier Entscheidungen zurückführen. Wer sie kennt, kann den Rest ableiten.

2. Die Landschaft auf einen Blick

Links die Werkzeuge, mit denen man redet. In der Mitte der Manager, der als einziger Prozesse startet. Rechts die Fachdaemons, die selbst wieder ganz normale Units sind. Unten der cgroup-Baum, in den jeder gestartete Prozess einsortiert wird.

Der einzige Prozess, der Dienste startet, ist PID 1. Alles andere — auch systemctl — schickt nur Aufträge über D-Bus dorthin und wartet auf das Ergebnis. Deshalb bricht der Bootvorgang nicht ab, wenn dbus-daemon noch nicht läuft: PID 1 hört zusätzlich auf einem privaten Socket unter /run/systemd/private.

3. PID 1 und der Manager pro Benutzer

Dasselbe Binary läuft in zwei Rollen: einmal als Systemmanager mit UID 0, und einmal pro angemeldetem Benutzer als dessen persönlicher Manager. Beide haben eigene Unit-Suchpfade und eigene Konfigurationsdateien.

Zusätzlich steuerbar ist PID 1 über die Kernel-Kommandozeile: systemd.unit=, systemd.mask=, systemd.log_level=. systemctl selbst startet nichts, sondern übersetzt Unterbefehle in Methodenaufrufe auf org.freedesktop.systemd1. Mit --user, --machine= und --host= wählt man den Manager, den man anspricht.

Die Abhängigkeitsverben — der Teil, an dem eigene Units scheitern

Es gibt zwei unabhängige Achsen: wer muss mitlaufen und in welcher Reihenfolge. Wer nur die erste setzt, bekommt einen Dienst, der parallel zu seiner Voraussetzung startet und mit einer Verbindungsfehlermeldung stirbt.

4. Die elf Unit-Typen

Die Dateiendung bestimmt den Typ. Jeder Typ hat neben den gemeinsamen Abschnitten [Unit] und [Install] einen eigenen Abschnitt mit den typspezifischen Direktiven.

5. Die Boot-Kette

Die obere Reihe ist echte Sequenz — jede Stufe übergibt an die nächste. Die untere Reihe sieht auch nach Sequenz aus, ist aber nur eine Ordnungsbeziehung: innerhalb jeder Stufe läuft alles parallel, was nicht ausdrücklich geordnet wurde.

Warum das praktisch zählt: Ein Dienst, der ins Netz muss, gehört hinter network-online.target — nicht hinter network.target, das nur besagt, dass die Netzwerkverwaltung gestartet wurde. Und wer den Bootvorgang vermessen will, nimmt systemd-analyze critical-chain: das zeigt die Ordnungskette, die die Bootzeit tatsächlich bestimmt hat, statt nur die langsamsten Units aus systemd-analyze blame.

6. Komponenten-Katalog mit allen Konfigurationspfaden

Alle *.conf-Dateien unter /etc/systemd/ folgen demselben Muster: Hauptdatei plus ein gleichnamiges .conf.d/-Verzeichnis daneben, dessen Schnipsel obendrauf gelegt werden.

Protokollierung, Sitzungen und Benutzer

Netz, Namen und Zeit

Geräte, Boot und Speicher

Isolation und Ressourcen

Einmal-Dienste beim Boot

Diese laufen einmal durch, hinterlassen einen Zustand und beenden sich. Alle folgen demselben Muster: ein Verzeichnis mit Schnipseln unter /usr/lib/ für Pakete und unter /etc/ für den Administrator, wobei eine gleichnamige Datei in /etc/ die des Pakets vollständig ersetzt.

7. Generatoren — die unsichtbare Übersetzungsschicht

Vor jedem daemon-reload ruft PID 1 alle ausführbaren Dateien in den Generator-Verzeichnissen auf. Jeder darf Units nach /run/systemd/generator*/ schreiben. So werden Formate zu Units, die nie als Unit gedacht waren — und deshalb findet man eine .mount-Unit, die man nirgends angelegt hat.

8. Konfigurationsmodell und Drop-ins

Das ganze Modell beruht auf einer Trennung: /usr/lib/ gehört der Distribution und wird bei jedem Update überschrieben, /etc/ gehört dem Administrator und wird nie angefasst, /run/ gilt nur bis zum Neustart. Dazu kommt ein zweiter Mechanismus, der oft übersehen wird — Drop-ins.

Die zwei Mechanismen verhalten sich gegensätzlich, und das ist die häufigste Verwirrung: bei der Unit-Datei gewinnt genau eine und verdeckt die anderen vollständig; bei Drop-ins werden alle gefundenen Schnipsel aus allen drei Ebenen angewandt, sortiert nach ihrem Dateinamen. Trägt ein Drop-in denselben Dateinamen wie eines aus /usr/lib/, ersetzt die Fassung aus /etc/ es punktgenau.

Der Weg, den man in der Praxis nimmt

# Nie die Paketdatei editieren - ein Update überschreibt sie kommentarlos.
# Stattdessen ein Drop-in anlegen; der Editor öffnet eine leere Datei:
systemctl edit nginx.service          # -> /etc/systemd/system/nginx.service.d/override.conf
systemctl edit --drop-in=limits nginx.service   # eigener Dateiname statt override.conf
systemctl edit --runtime nginx.service          # nur bis zum Reboot, nach /run
systemctl edit --full nginx.service             # doch die ganze Datei - Kopie nach /etc

# Ergebnis kontrollieren
systemctl cat nginx.service          # Basisdatei + alle Drop-ins, in Reihenfolge
systemctl show nginx.service -p ExecStart -p MemoryMax
systemd-analyze verify /etc/systemd/system/eigen.service

# Was hat systemd überhaupt geladen und woher?
systemd-analyze unit-paths            # alle Suchpfade in Rangfolge
systemd-analyze cat-config systemd/journald.conf   # dasselbe für *.conf.d

# Nach jeder Änderung an einer Unit-Datei:
systemctl daemon-reload                # neu einlesen
systemctl restart nginx.service        # erst das wendet sie auf den Prozess an

9. Eine Unit-Datei, Zeile für Zeile

Drei Abschnitte, jeder mit einer klaren Zuständigkeit: [Unit] beschreibt Beziehungen zu anderen Units, der typspezifische Abschnitt beschreibt das Verhalten, [Install] beschreibt nur, was beim enable passieren soll.

# /etc/systemd/system/backup-export.service

[Unit]
Description=Nächtlicher Export nach S3
Documentation=https://wiki.intern/backup-export
After=network-online.target postgresql.service   # Reihenfolge ...
Wants=network-online.target                       # ... und wer mitkommen soll
Requires=postgresql.service                       # harte Kopplung: DB weg => wir auch
ConditionPathExists=/srv/export                   # Condition: still überspringen ...
AssertPathIsDirectory=/srv/export                 # ... Assert: laut scheitern
StartLimitIntervalSec=300
StartLimitBurst=3                                 # mehr als 3 Fehlstarts in 5 min => Aufgabe

[Service]
Type=oneshot                # simple | exec | forking | oneshot | notify | dbus | idle
User=backup
Group=backup
WorkingDirectory=/srv/export
EnvironmentFile=-/etc/default/backup-export        # führendes "-": darf fehlen
Environment="LC_ALL=C"
ExecStartPre=/usr/local/bin/export-check
ExecStart=/usr/local/bin/export-run --target=s3
ExecStopPost=/usr/local/bin/export-cleanup         # läuft auch nach Fehlschlag
TimeoutStartSec=30min
Restart=on-failure                                 # no | on-failure | always | on-abnormal
RestartSec=30

# Verzeichnisse, die systemd anlegt, aufräumt und rechtemässig dem User gibt:
RuntimeDirectory=backup-export        # /run/backup-export
StateDirectory=backup-export          # /var/lib/backup-export
LogsDirectory=backup-export           # /var/log/backup-export
CacheDirectory=backup-export          # /var/cache/backup-export

# Sandbox - Details im Abschnitt "Härten"
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
NoNewPrivileges=yes
ReadWritePaths=/srv/export

[Install]
WantedBy=multi-user.target        # wirkt erst bei "systemctl enable"

Der zugehörige Timer — der cron-Ersatz

# /etc/systemd/system/backup-export.timer
# aktivieren mit: systemctl enable --now backup-export.timer

[Unit]
Description=Startet den Export täglich um 02:30

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true              # verpasste Läufe nachholen (Maschine war aus)
RandomizedDelaySec=15min     # entzerrt viele Hosts mit derselben Zeit
AccuracySec=1min             # Standard ist 1min, nicht sekundengenau
Unit=backup-export.service   # optional; sonst gleicher Name mit .service

[Install]
WantedBy=timers.target

Type= richtig wählen — die häufigste Ursache für hängende Starts

10. cgroups: Buchführung und Grenzen

Weil ohnehin jede Unit ihre eigene cgroup hat, kosten Limits nichts extra — sie sind ein paar Zeilen in derselben Datei. Der Baum ist hierarchisch: was am Slice hängt, gilt für alle Units darin gemeinsam.

# Sehen, wer was verbraucht
systemd-cgls                          # der Baum, mit Prozessen
systemd-cgtop                         # wie top, aber pro Unit statt pro Prozess
systemctl status nginx.service        # zeigt Memory, Tasks, CPU der cgroup

# Grenze setzen, ohne eine Datei zu öffnen - schreibt ein Drop-in nach /etc/...d/
systemctl set-property nginx.service MemoryHigh=2G MemoryMax=3G
systemctl set-property --runtime backup.service CPUQuota=40%   # nur bis Reboot

# Ein eigenes Slice für eine Gruppe von Diensten:
#   /etc/systemd/system/batch.slice
#     [Slice]
#     CPUQuota=300%
#     MemoryMax=8G
#   ... dann in jeder Unit:  Slice=batch.slice

# Einmalig etwas eingesperrt laufen lassen, ohne Unit-Datei
systemd-run --scope -p MemoryMax=1G -p CPUQuota=50% ./import.sh
systemd-run --unit=nachtlauf --on-calendar="*-*-* 03:00" /usr/local/bin/job

11. Härten ohne Container

Dieselben Kernel-Mechanismen, die Container ausmachen — Namespaces, Capabilities, seccomp, Bind-Mounts — stehen jeder Unit als Direktiven zur Verfügung. Ein Dienst lässt sich damit deutlich enger führen als in vielen Container-Setups, ohne ein Image zu bauen.

# Bewertung der eigenen Units - 0 = uneinnehmbar, 10 = völlig offen
systemd-analyze security                      # alle Dienste, sortiert
systemd-analyze security nginx.service        # zeilenweise, mit Begründung je Direktive

# Vorgehen: schrittweise zuschrauben, nach jedem Schritt neu starten und prüfen.
# Fehlschläge stehen im Journal - bei seccomp meist als "Operation not permitted".
journalctl -u nginx -b --since "5 min ago" -p warning

12. Werkzeugkasten

13. Praxis auf Debian- und Proxmox-Systemen

Ablauf, wenn eine Unit nicht startet

systemctl status foo.service            # 1. Zustand, Exit-Code, letzte 10 Journal-Zeilen
journalctl -u foo.service -b --no-pager  # 2. der ganze Verlauf dieses Boots
systemctl cat foo.service               # 3. was ist wirklich konfiguriert, inkl. Drop-ins
systemd-analyze verify foo.service      # 4. Syntax und unbekannte Direktiven
systemctl list-dependencies foo.service --after   # 5. wartet sie auf das Richtige?
systemctl show foo.service -p Conditions -p ExecMainStatus  # 6. still übersprungen?

# Läuft der Dienst von Hand, aber nicht als Unit, ist es fast immer die Sandbox
# oder die Umgebung. Zum Gegenprüfen mit identischer Umgebung starten:
systemd-run --pty --same-dir --wait --collect --service-type=exec \
  --property=User=backup /usr/local/bin/export-run --target=s3