Das Init-System Systemd, Teil 2

Test & Kaufberatung | Test

Aktuelle Versionen von Fedora, OpenSuse, Mandriva und einigen anderen Distributionen starten das System bereits mit Systemd. Das neue Init-System bringt eigene Werkzeuge zur Konfiguration und Diagnose mit und erfordert andere Kniffe als Sysvinit, wenn es Probleme gibt.

Das Init-System Systemd, Teil 2

Aktualisierte Version des Artikels "Anschmeißer" aus c't 13/11, S. 176.

Siehe dazu auch:


Das neue Init-Tool Systemd liegt schon mehreren Distributionen als Alternative zu Upstart oder dem angestaubten Sysvinit bei. Einige von Sysvinit- und Upstart-Distributionen gewohnte Kommandos und Tricks arbeiten durch Kompatibilitätsmaßnahmen auch unter Systemd. Um die Fähigkeiten von Systemd richtig zu nutzen, sollte der Administrator allerdings auch Werkzeuge und Parameter von Systemd kennen.

Zu den Autoren

Lennart Poettering und Kay Sievers haben Systemd entworfen und entwickelt. Während der Entstehung des Artikels arbeitete Poettering bei Red Hat und Sievers bei Novell.

Wichtigstes Tool zur Interaktion mit Systemd ist das Kommandozeilenprogramm systemctl. Für Änderungen an der Konfiguration oder den Neustart von Hintergrunddiensten erfordert es Root-Rechte; einige Diagnose-Aufrufe dürfen auch einfache Anwender ausführen. Wer das Programm ohne jegliche Parameter aufruft, erhält eine Liste der "Units", die beim Systemstart anfallende Aufgaben erledigen. Dazu gehört neben dem Einbinden und Prüfen von Datenträgern auch das Starten von Hintergrunddiensten oder das Einrichten von Hardware.

Bei einer Standardinstallation von Fedora 16 listet Systemctl rund hundertsechzig aktive Units in zehn verschiedenen Spielarten. Zu den wichtigsten zählen Service-Units. Sie kümmern sich um Hintergrunddienste, die eine Sysvinit-Distribution typischerweise über Init-Skripte startet. Mount- und Automount-Units binden Dateisysteme ein. Socket-Units legen Sockets an; sie starten indirekt über Abhängigkeiten einen andere Unit, sobald auf den Socket zugegriffen wird. (Eine detaillierte Erläuterung des Unit-Konzepts finden Sie im ersten Teil des Artikels.)

Über einen Parameter kann man Systemctl anweisen, nur Units eines bestimmten Typs aufzulisten, etwa alle Service-Units:

systemctl --type=service 

Systemctl leitet seine Ausgabe automatisch an less weiter; über die Pfeiltasten lässt sich nicht nur hoch- und runterscrollen, sondern auch nach rechts, denn dort verbergen sich manchmal weitere Informationen.

Den Systemstart erledigt Systemd mit Units. Die gibt es in verschiedenen Spielarten, die Systemctl separat auflisten kann.
Vergrößern Den Systemstart erledigt Systemd mit Units. Die gibt es in verschiedenen Spielarten, die Systemctl separat auflisten kann.

In der ersten Spalte der Ausgabe findet sich der Unit-Name. Die zweite Spalte gibt an, ob Systemd die Unit-Definition laden konnte, die dritte, ob die Unit aktiv ist. Inaktive – installierte, aber nicht zum Start vorgesehene – Units gibt das Programm nur mit dem Schalter -a aus; dasselbe gilt für Units, die das Init-System etwa aufgrund eines Fehlers in der Unit-Datei nicht laden konnte.

Spalte vier liefert den aktuellen Status. "exited" zeigt an, dass sich der Prozess ohne Fehler beendet hat. Das ist zum Beispiel bei Diensten der Fall, die im Hintergrund weiterlaufen – etwa bei der Service-Unit, die aus Kompatibilitätsgründen die von Sysvinit bekannte Datei /etc/rc.local beim Systemstart ausführt. "running" steht bei Diensten, die im Hintergrund laufen: cron, dbus, sshd, udev und andere.

In der fünften Spalte folgt eine Beschreibung der Unit. Wenn sie mit "LSB" oder "SYSV" beginnt, hat Systemd die Unit automatisch erzeugt, um ein traditionelles Init-Skript abzuarbeiten.

Bei Diensten, die nicht gestartet werden konnten oder später abgestürzt sind, steht in der vierten Spalte "failed" – rot hervorgehoben, sofern die Konsole farbige Ausgabe beherrscht. Das status-Kommando von sytemctl gibt den Zeitpunkt des Abbruchs und den zurückgelieferten Fehlercode des Programms aus, beispielsweise

systemctl status NetworkManager.service

Das Status-Kommando von Systemctl liefert Abbruchzeit und Fehlercode abgestürzter Dienste.
Vergrößern Das Status-Kommando von Systemctl liefert Abbruchzeit und Fehlercode abgestürzter Dienste.

Bei einem frisch installierten Fedora 16 listet Systemctl um die 60 Service-Units auf. Darunter sind auch die Login-Prozesse für die Textkonsolen (agetty), denn anders als Sysvinit handhabt Systemd diese über Service-Units wie einen normalen Hintergrunddienst.

Die Konfigurationsdateien zum Erzeugen der Units, die Systemd mitbringt, liegen in /lib/systemd/system/; eine gleichnamige Datei in /etc/systemd/system/ hat jedoch Vorrang.

Unit-Definition sind meist deutlich kürzer als die klassischen Sys-V-Init-Skripte. Eine Unit-Datei für den Dienst zur Netzwerkzeit-Synchronisierung via NTP ist nur wenige Zeilen lang:

[Unit]
Description=Network Time Service

[Service]
ExecStart=/usr/bin/ntpd -n -u ntp:ntp -g

[Install]
WantedBy=multi-user.target

Alle Unit-Dateien enthalten einen durch [Unit] eingeleiteten Abschnitt mit allgemeinen Einstellungen, darunter eine kurze Beschreibung. Im Abschnitt [Service] folgen dienstspezifische Angaben; bei NTP ist das lediglich das Kommando, um den Dienst zu starten. Falls ein spezieller Befehl zum Beenden nötig ist, kann man diesen über eine ExecStop-Anweisung festlegen. Beim NTP-Daemon ist das unnötig, weil er sich in guter Unix-Tradition durch ein SIGTERM-Signal beenden lässt; das sendet Systemd zum Beenden, wenn kein anderer Befehl spezifiziert ist.

Der Abschnitt [Install] enthält Anweisungen, die Systemd bei der (De-)Installation interpretiert; der Eintrag im NTP-Beispiel bedeutet, dass die Zeitsynchronisation beim Ansteuern des Targets "Multi-User" aufgerufen werden soll.

Die Targets-Units bieten ein Konzept, das den Runlevels von Sysvinit ähnelt; aus Kompatibilitätsgründen versteht Systemd sogar die Runlevel-Namen zur Ansteuerung äquivalenter Targets. Wie gewohnt kann man daher bei Fedora 16 dem Kernel im Boot-Loader den Parameter single mitgeben; Systemd steuert daraufhin rescue.target an, das eine minimale, dem Single-User-Modus entsprechende Umgebung bietet.

Auch 3 funktioniert, um den Multi-User-Modus ohne grafischen Anmeldemanager anzusteuern. Repräsentiert wird dieser Modus in Systemd durch die Target-Unit multi-user. Um multi-user.target zum Standard zu machen, reicht ein Links:

ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target 

Soll der grafische Anmeldemanager später doch wieder standardmäßig starten, kann man auf die gleiche Weise graphical.target zum Standardziel erheben; es ist das Äquivalent zum Runlevel 5 von Fedora und OpenSuse. Alternativ zu den alten Runlevel-Bezeichnungen kann man dem Kernel auch die Namen der zu startenden Target-Unit mitgeben:

systemd.unit=multi-user.target 

Um im Betrieb eine andere Target-Unit anzusteuern, dient das isolate-Kommando von Systemctl:

systemctl isolate rescue.target 

Der Wechsel in das Rescue-Target ist für Administrationsaufgaben interessant, denn dabei beendet Systemd alle User-Logins und Hintergrunddienste, sodass nur noch Systemdienste laufen – etwa jene zur Überwachung von Logical Volumes (lvm2-monitor). Manchmal müssen auch diese für Umbauten heruntergefahren werden, was mit dem Notfall-Modus emergency.target gelingt; hier laufen nur noch die Kernel-Threads.

Forum zum Thema

Kommentare

Kommentare lesen (102 Beiträge)

Anzeige