Auf fast allen modernen Linux-Distributionen kümmert sich inzwischen Systemd um den Systemstart – und mehr. Wir erklären, wie die neue Schaltzentrale funktioniert.

Beim Booten durchläuft Ihr Linux-Rechner mehrere Phasen, bis Sie schließlich den Loginmanager oder den Desktop (bei automatischer Anmeldung) Ihrer Distribution sehen. Zuerst startet das BIOS bzw. UEFI auf moderneren Systemen, um die Hardware zu erkennen. Danach nimmt der Bootloader den Dienst auf – bei den meisten Distributionen ist das Grub 2. Der Bootloader kümmert sich unter anderem um den Linux-Kernel und die Initial RAM Disk (Initrd). Erst nachdem beide Komponenten geladen sind, startet der erste “richtige” Prozess.

Bis vor Kurzem kümmerte sich SysVinit um das Einrichten der Distribution beim Booten. Das Init-System hatte die Aufgabe, weitere Dienste zu starten, z. B. das Netzwerk, den Druckdienst, den Mehrbenutzermodus, die grafische Arbeitsumgebung usw. Der erste Prozess führt traditionell das Programm /sbin/init aus, hat die PID (Prozess-ID, Prozessnummer) 1 und wird als “Init-Prozess” bezeichnet. In der Baumansicht der Prozesse (die in “Vater-Sohn”-Beziehungen zueinander stehen, wenn ein Prozess einen anderen gestartet hat) bildet der Init-Prozess die Wurzel [1] des Baums.

Höher, schneller, weiter

SysVinit gehört zum Unix-Betriebssystem System V (“System Five”) von der Firma AT&T. Der Nachfolger von System III stammt aus dem Jahr 1983 – und genau so alt ist das Konzept des dazugehörigen Init-Systems, das die verschiedenen Linux-Distributionen bis vor Kurzem als Nachbau genutzt haben. Es kennt keine Abhängigkeiten, keine Events (Ereignisse) und hält sich beim Starten von Diensten strikt an die durch die so genannten Runlevel vorgegebene Reihenfolge. Zum Starten, Stoppen und Neustarten von Diensten nutzten die Systeme Shell-Skripte, die beispielsweise in /etc/init.d oder /etc/rc.d lagen und über symbolische Links den Runleveln zur Verfügung gestellt wurden. Dabei musste SysVinit jeweils warten, bis ein bestimmter Dienst fertig initialisiert war, bevor der nächste an die Reihe kam.

Das relativ starre Konzept sorgte dafür, dass der Rechnerstart einige Zeit in Anspruch nahm. Immer wieder versuchten einzelne Distributionen, neue Wege zu beschreiten, um den Vorgang zu beschleunigen. So führte Ubuntu im Jahr 2006 das ereignisorientierte Init-System Upstart [2] ein, und eine Weile sah es so aus, als würden auch andere Distributionen auf diesen Zug aufspringen: Fedora und OpenSuse stiegen zunächst auf den SysVinit-Nachfolger um. Dann aber kam das Jahr 2010, und die beiden Entwickler Lennart Poettering und Kay Sievers traten an, das Bootkonzept zu revolutionieren. Mit ihrer Erfindung Systemd [3] sorgten sie aber nicht nur für einen flotten Start, sondern warfen gleich eine ganze Reihe von altbewährten Methoden über Bord.

Der System- und Dienstemanager Systemd ist als eine Art eierlegende Wollmilchsau konzipiert. Er soll nicht nur alle gestarteten Dienste und Programme im Auge behalten, sich um das Einhängen (Mounten) von Dateisystemen und das Einrichten von Netzwerkverbindungen kümmern, sondern künftig z. B. auch die Uhrzeit synchronisieren und den Cron-Dienst ersetzen. Seit 2010 sind nach und nach fast alle großen Linux-Distributionen umgestiegen, und sogar Ubuntu hat das eigene Upstart-System zugunsten von Systemd aufgegeben. Für Sie als Benutzer ändert sich wenig – wenn Sie sich aber dafür interessieren, was unter der Haube läuft, geben die nächsten Abschnitte einen Überblick über die wichtigsten Funktionen.

Die neue Nummer 1

Der Systemd-Prozess erhält genau wie früher /sbin/init die PID 1; er ist damit die Wurzel des Prozessbaums. Wie die Vater-Sohn-Beziehungen der Prozesse aussehen, können Sie sich beispielsweise mit dem Kommando pstree anschauen, das Sie in ein Terminalfenster oder in eine der virtuellen Konsolen eingeben (Abbildung 1). Systemd aktiviert beim Booten zunächst nur Dienste, die unmittelbar benötigt werden – und zwar gleichzeitig. Das klingt anfangs etwas verwirrend: Schließlich kann ein Web- oder Mailserver nur dann richtig arbeiten, wenn das Netzwerk bereits eingerichtet ist.

Abbildung 1: Am Anfang steht nicht länger “init” – “systemd” ist jetzt die Nummer 1.

Damit nichts und niemand den Bootprozess blockiert, gaukelt Systemd den Diensten vor, dass alle benötigten Komponenten direkt vorhanden sind. Dazu richtet Systemd so genannte Sockets ein, welche die Prozesse zum Kommunizieren untereinander nutzen. Das passiert schon, bevor ein Dienst vollständig gestartet wurde. Systemd fängt Nachrichten über diese Sockets ab und speichert sie so lange zwischen, bis der benötigte Service tatsächlich läuft und selbst antworten kann. Das Ganze spart nicht nur Zeit, sondern hat einen praktischen Nebeneffekt: Systemd kontrolliert die Sockets weiter, bemerkt, wenn ein Service abgestürzt ist, und kann ihn ggf. neu starten. Ein Artikel in unserer Schwesterzeitschrift LinuxUser [4] beschreibt ausführlich, wie das Ganze funktioniert.

Einheitlich

Systemd organisiert seine Aufgaben in Units (dt. “Einheiten”). Dabei handelt es sich um kleine und relativ übersichtliche Konfigurationsdateien, die von der Syntax her den .ini-Dateien unter Windows ähneln. Als reiner Linux-Anwender kommen Sie in der Regel mit diesen Units nicht in Berührung; dennoch ist es gut zu wissen, welchen Zweck sie erfüllen und wo sie liegen. Die wichtigsten drei Typen sind:

• Service-Units (Dateiendung .service): Sie starten und stoppen Hintergrunddienste, z. B. den SSH-Server, den Druckdienst CUPS, den Webserver Apache usw.
• Mount-/Automount-Units: Diese Units kümmern sich um das Ein- und Aushängen von Dateisystemen. Sie tragen die Endung .mount bzw. .automount, wenn ein Automounter beteiligt ist.
• Target-Units (Endung .target): Das sind Gruppen aus mehreren Units, die gleichzeitig starten sollen. So kümmert sich network.target z. B. um alle Netzwerkkomponenten oder graphical.target um die grafische Arbeitsoberfläche. Targets können aufeinander aufbauen und voneinander abhängen.

Ubuntu lagert die Units im Verzeichnis /lib/systemd/system (Abbildung 2); OpenSuse bewahrt sie hingegen in /usr/lib/systemd/system auf. Die von den Distributionen erzeugten Units sollten Sie nicht verändern. Müssen oder wollen Sie selbst etwas anpassen, ist das Verzeichnis /etc/systemd/system der richtige Ort auf allen Systemen.

Abbildung 2: Die Distributionen wählen unterschiedliche Aufbewahrungsorte für die Units. Ubuntu beispielsweise lagert sie in “/lib/systemd/system”.

In einer Unit-Datei ist unter anderem definiert, wie der Dienst heißt und wie der Startbefehl (ggf. mit Aufrufparametern) lautet. Außerdem stehen hier bei Bedarf Abhängigkeiten zu anderen Services; sogar die Reihenfolge für weitere Units und Targets kann hier explizit genannt werden. Ein SSH-Server soll beispielsweise erst dann die Arbeit aufnehmen, wenn das Netzwerk konfiguriert ist. Auch beim Beenden kann die Reihenfolge entscheidend sein: Der Rechner darf nicht herunterfahren, bevor die Dateisysteme ordentlich ausgehängt und alle Prozesse sauber beendet wurden.

Richtig diagnostiziert

Mit dem Kommando systemctl steuern Sie Systemd auf der Shell. Reine Abfragefunktionen können Sie auch als nicht-privilegierter Benutzer nutzen; das Ändern der Konfiguration, Starten und Stoppen von Diensten ist root vorbehalten. Geben Sie den Befehl ohne weitere Parameter ein, listet er alle geladenen Units auf. In der langen Liste blättern Sie mit den Pfeiltasten, und [Q] schließt die Anzeige. Ein angehängtes --all blendet zusätzlich die inaktiven Units ein, und hinter --type= können diverse Filter stehen. So sortieren Sie die Ausgabe beispielsweise nach service, target oder mount. Dienste, die abgestürzt oder gar nicht erst gestartet sind, zeigt systemctl in Rot an. Eine gezielte Statusabfrage für einen Dienst führen Sie mit systemctl status durch.

Systemd bringt ein weiteres Diagnosetool mit, das unter anderem verrät, wie schnell der Rechner gebootet hat (systemd-analyze). Zusammen mit der Option blame druckt es ins Terminal eine Liste mit den Diensten, die am längsten gebraucht haben. Ein Ubuntu-Testsystem brauchte beispielsweise insgesamt rund 13 Sekunden zum Booten, ein OpenSuse-Rechner mehr als 3 Minuten. Der Parameter blame spürte den Übeltäter auf – verantwortlich für die Verzögerung war hier systemd-udev-settle.service (Abbildung 3).

Abbildung 3: Mit den richtigen Diagnosewerkzeugen (“systemd-analyze”) erfahren Sie auch als normaler Benutzer, was den Bootvorgang verzögert hat.

Schriftführer

Systemd enthält eine eigene Logfunktion namens Journald. Sie dient als Ersatz für Syslog, kann aber auch mit den anderen Loggingdiensten Hand in Hand arbeiten. Das Systemd-Protokoll liegt in einem binären Format vor; OpenSuse-Nutzer finden es unter /var/log/journal, Ubuntu-Anwender unter /run/log/journal. Da es sich nicht um eine Textdatei handelt, fallen Programme wie less und more zum Betrachten aus. Stattdessen gibt es ein eigenes Werkzeug namens journalctl, das ohne weitere Aufrufoptionen das gesamte Protokoll mit allen Einträgen ausgibt.

Über Parameter sortieren und filtern Sie die Meldungen. So können Sie gezielt nach bestimmten Units suchen (--unit=), nach Notfällen, kritischen und weniger kritischen Fehlern filtern oder Datumsbereiche gezielt vorgeben. Die Option –disk-usage verrät, wie viel Plattenplatz das Journal gerade verbraucht:

$ journalctl --disk-usage
Archived and active journals take up 16.0M on disk.

Als Äquivalent zu tail -f, das ein Logfile beobachtet und die Anzeige fortlaufend aktualisiert, dient der Aufruf journalctl -f.

Geschiedene Geister

Viele Administratoren und Entwickler finden den Umstieg auf Systemd gut und erleben ihn als echte Arbeitserleichterung. Sie vermissen die teilweise recht kryptischen Shell-Skripte aus /etc/init.d nicht und bevorzugen die eingängige Syntax der Unit- und Target-Dateien. Dass sich die einzelnen Linux-Distrubutionen dabei angleichen und grundlegende Konzepte vereinheitlichen, gefällt ebenfalls vielen Systemverwaltern.

Andere kritisieren, dass Systemd zu viele Aufgaben übernimmt und damit die seit Langem geltende Unix-Philosophie “ein Tool für eine Aufgabe, und die erledigt es gut” verletzt. Regen Protest gab es auch wegen der Logfiles im Binärformat. Dass Systemd nur auf Linux-Kernen läuft und eine Portierung auf andere Unix-Derivate momentan unwahrscheinlich ist, stört ebenfalls einige Entwickler.

Fast keine Neuerung hat die Linux-Community so gespalten wie Systemd. Auf den Mailinglisten tobten monatelang wahre Kleinkriege, auf Konferenzen sowie in Chaträumen wurde erhitzt diskutiert, und etliche bekannte Entwickler nahmen ihren Hut und verabschiedeten sich aus laufenden Projekten. Die bekannteste Abspaltung dürfte derzeit Devuan [5] sein – ein Debian-Fork ohne Systemd. Andere Nutzer veröffentlichen fleißig Anleitungen, um SysVinit zurück aufs Lieblingssystem zu bringen, und wieder andere Entwickler forken Systemd selbst, um das Programm wieder auf einen reinen Init-Dienst zu beschränken [6].

Nutzen Sie eine der von EasyLinux unterstützten Distributionen (OpenSuse oder Kubuntu), werden Sie höchstwahrscheinlich noch eine Weile mit Systemd leben müssen. Alternativ können Sie Linux Mint ausprobieren, das derzeit noch Upstart einsetzt.