Systemd Einführung

Was ist systemd

systemd ist der Init-Prozess (PID 1) moderner Linux-Systeme und damit die erste Instanz, die der Kernel nach dem Boot startet. Es ersetzt die klassischen SysV-Init-Skripte und bringt ein grundlegend anderes Konzept mit:

Kernpunkte

• Deklarativ statt skriptbasiert – Dienste werden über Unit-Files beschrieben (Was, nicht Wie), keine Shell-Skripte mehr wie bei SysV-Init
• Paralleler Start – Units werden basierend auf Abhängigkeiten gleichzeitig gestartet, nicht mehr sequentiell nach Runlevel-Nummer
• Socket-/D-Bus-Activation – Dienste starten erst bei tatsächlichem Bedarf, nicht pauschal beim Boot
• Einheitliches Konzept für mehr als nur Dienste – Mounts, Timer, Netzwerkgeräte, Sockets, Pfade laufen alle über dasselbe Unit-System

Verwaltet werden unter anderem

• Dienste (.service)
• Mountpoints (.mount)
• Geplante Aufgaben (.timer, ersetzt Cron für systemd-verwaltete Aufgaben)
• Netzwerkgeräte (.network, über systemd-networkd)
• Sockets (.socket)

systemctl

Grundoperationen

systemctl status sshd
systemctl start sshd
systemctl stop sshd
systemctl restart sshd
systemctl reload sshd          # Konfig neu laden ohne Neustart (falls vom Dienst unterstützt)
systemctl enable sshd          # beim Boot automatisch starten
systemctl disable sshd
systemctl enable --now sshd    # enable + start in einem Schritt
systemctl mask sshd            # Start komplett verhindern, auch manuell

Übersicht verschaffen

systemctl list-units --type=service          # aktive Services
systemctl list-unit-files --type=service      # alle bekannten Services + enabled/disabled-Status
systemctl list-dependencies sshd              # Abhängigkeitsbaum einer Unit

Nach Änderungen an Unit-Files

systemctl daemon-reload

Targets

Targets sind Gruppierungen von Units, das systemd-Äquivalent zu klassischen Runleveln.

Target	entspricht Runlevel	Bedeutung
poweroff.target	0	System herunterfahren
rescue.target	1	Einzelbenutzermodus, minimale Umgebung
multi-user.target	3	Mehrbenutzerbetrieb ohne grafische Oberfläche (Standard auf Servern)
graphical.target	5	Mehrbenutzerbetrieb mit grafischer Oberfläche
reboot.target	6	Neustart
emergency.target	S	absolutes Minimum, sogar ohne Mounts – Notfall-Shell

systemctl get-default                     # aktuelles Standard-Target anzeigen
systemctl set-default multi-user.target   # Standard-Target dauerhaft ändern
systemctl isolate multi-user.target       # sofort in anderes Target wechseln

journalctl

Das Alltags-Kommando

Unit live verfolgen

journalctl -fu sssd

Kombiniert mit Textfilter

journalctl -fu sssd -g "authentication"

Weitere Kombinationen, die im Alltag wirklich vorkommen

journalctl -u sshd --since today
journalctl -u sshd --since "2026-07-01" --until "2026-07-02"
journalctl -b                    # nur seit letztem Boot
journalctl -b -1                 # vorheriger Boot
journalctl -p err                # nur Priorität "error" und höher
journalctl -k                    # nur Kernel-Meldungen (entspricht dmesg)
journalctl --disk-usage          # wie viel Platz belegt das Journal
journalctl --vacuum-time=2weeks  # alte Einträge löschen

Persistenz

Standardmäßig liegt das Journal nur in /run/log/journal (RAM, weg nach Reboot). Für dauerhaftes Logging:

mkdir -p /var/log/journal
systemctl restart systemd-journald

Eigene Service-Unit erstellen

Klassisches Beispiel – ein einfacher Python-HTTP-Server als systemd-Dienst:

# /etc/systemd/system/webtest.service
[Unit]
Description=Einfacher Python HTTP-Server
After=network.target

[Service]
ExecStart=/usr/bin/python3 -m http.server 8080 --directory /srv/www
WorkingDirectory=/srv/www
User=nobody
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now webtest.service
systemctl status webtest.service

Wichtigste Directives im Überblick

Directive	Bedeutung
After / Requires	Reihenfolge- bzw. echte Abhängigkeit zu anderen Units
Type=simple	Standard: Prozess bleibt im Vordergrund, gilt sofort als gestartet
Type=forking	klassischer Daemon, der sich selbst forkt (z. B. traditionelle Daemons)
Restart=on-failure	automatischer Neustart bei Absturz
WantedBy=multi-user.target	legt fest, zu welchem Target die Unit bei enable hinzugefügt wird

Weitere Unit-Typen

.mount – Mountpoints als Unit

Alternative zu /etc/fstab, wird aber meist automatisch aus fstab generiert. Eigene .mount-Units sind sinnvoll bei komplexeren Abhängigkeiten (z. B. Mount erst nach einem bestimmten Service).

# /etc/systemd/system/srv-daten.mount
[Unit]
Description=Datenpartition

[Mount]
What=/dev/sdb1
Where=/srv/daten
Type=xfs
Options=defaults

[Install]
WantedBy=multi-user.target

Wichtig: Der Dateiname muss exakt dem Mountpoint entsprechen (/ wird zu -), sonst wird die Unit ignoriert.

.timer – ersetzt Cron für systemd-verwaltete Aufgaben

Ein Timer braucht immer eine gleichnamige .service-Unit als Gegenstück.

# /etc/systemd/system/backup.timer
[Unit]
Description=Tägliches Backup

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

[Install]
WantedBy=timers.target

systemctl enable --now backup.timer
systemctl list-timers                 # alle Timer mit nächster Ausführungszeit

.network – systemd-networkd (Alternative zu NetworkManager)

Auf Rocky-Systemen standardmäßig NetworkManager aktiv, aber in Containern/minimalen Images oft systemd-networkd im Einsatz. Syntax lohnt sich zu kennen:

# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0

[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
DNS=192.168.1.1

systemctl enable --now systemd-networkd
networkctl status
networkctl list

.socket – Socket-Activation

Ermöglicht, dass ein Dienst erst beim ersten eingehenden Verbindungsversuch tatsächlich gestartet wird (spart Ressourcen, klassisches Beispiel: sshd.socket bei manchen Distributionen, cups.socket).

systemctl list-sockets