Systemd gehört heute als fester Bestandteil zu vielen Distributionen. Den Platz als zentraler Baustein hat sich die Software jedoch hart erkämpfen müssen.

Vor 10 Jahren hat die erste Version von Systemd [1] den Weg in die freie Wildbahn gefunden. Der Daemon trat an, um dem in die Jahre gekommenen SysVinit [2] die Hoheit über den Prozess-ID 1, also den ersten Prozess beim Hochfahren des Linux-Rechners, zu entreißen. Der Ps-Befehl verrät, welches Init-System zum Einsatz kommt. Gibt er dabei nur /sbin/init aus, so offenbart meist ein ls darauf, dass dies ein Symlink zu Systemd ist (Abbildung 1 und**2).

Abbildung 1: Der Befehl ps -fp 1 weist Systemd als den Ursprung von PID 1, dem ersten Prozess beim Systemstart aus.

Abbildung 2: Bei manchen Distributionen zeigt die einfache Ps-Abfrage nur /sbin/init an. Der List-Befehl offenbart dann die Symlink-Beziehung zu Systemd.

Federführend bei Systemd waren die bei Red Hat angestellten Entwickler Lennart Poettering, Kai Sievers, Harald Hoyer und Tom Gunderson. Der erste Satz im Systemd-Wiki macht sofort klar, dass es um mehr geht als um einen reinen Init-Ersatz: “Systemd ist eine Suite von Grundbausteinen für ein Linux-System.”

Heftig umstritten

Das Projekt avancierte durch diesen Anspruch schnell zum vermutlich am heftigsten umstrittenen und polarisierenden Zankapfel der Linux-Geschichte. Die erbitterten Diskussionen, die ihren Höhepunkt in den Flame-Wars besonders bei Debian in den Jahren von 2012 bis 2014 erreichten, verließen oft sehr rasch die technische Ebene und drehten sich um Paradigmen aus der Unix-Zeit wie etwa “Do One Thing and Do It Well”, dem Systemd trotz seiner Modularität nach Ansicht der Kritiker diametral entgegenläuft.

Ein weiterer Kritikpunkt war die kategorische Festlegung auf Linux als einzig unterstütztes Betriebssystem, bedingt durch die intensive Nutzung von Techniken wie Cgroups und Capabilities, die sich in den Kernel anderer Betriebssysteme nicht finden. Die Qualität der Debatten ließ meist zu wünschen übrig und erreichte ihren Tiefpunkt mit der Androhung körperlicher Gewalt gegen Lennart Poettering.

Über Init hinaus

Die Kritiker waren und sind der Meinung, ein Init-System solle sich nur um den Init-Prozess, also PID 1 und die in der Folge gestarteten Prozesse bis zum Herunterfahren kümmern. Das beinhaltet das Starten, Überwachen und Beenden von Prozessen zur Laufzeit eines Rechners, wie es etwa SysVinit tut.

Systemd ging von Anfang an konzeptionell weit darüber hinaus, wie der erste mit “Rethinking PID 1” betitelte Eintrag vom April 2010 im lesenswerten 0pointer-Blog von Poettering belegt [3]. Ein Blick auf die direkt von Systemd gestarteten Prozesse bestätigt diesen Anspruch (Abbildung 3).

Abbildung 3: Der Blick auf die Prozesse, die Systemd direkt startet, zeigt die oft kritisierte tiefe Verzahnung mit dem gesamten System.

Vorgänger SysVinit

SysVinit war bis dahin das am häufigsten verwendete Init-System. Geschrieben für das Unix-Betriebssystem System V, erhielt es für Linux etliche Änderungen. Es arbeitet auf der Basis von Shell-Skripten, die meist unter /etc/init.d liegen. Über die Datei /etc/inittab legen Sie fest, welche Start- und Stop-Skripte in den verschiedenen Runlevel zum Einsatz kommen und in welcher Reihenfolge das geschieht.

Zu viel, zu langsam

Die Kritik Poetterings an diesem System bezog sich zunächst auf die Geschwindigkeit während des Bootens. Seine Erkenntnis war, dass zu viel gestartet wurde und dass dies sequentiell anstatt parallel geschah.

Systemd startet dagegen Prozesse parallel und nutzt, damit dabei kein Durcheinander entsteht, sogenannte Sockets, über die Dienste Reihenfolge und richtigen Zeitpunkt zum Start mittels Dbus verhandeln. Auf diese Weise ist es möglich, den Start von Diensten zwar vorzubereiten, diese aber erst bei bestimmten Ereignissen zu starten.

Ein weiterer Vorteil von Systemd ist die Einfachheit der Service-Dateien gegenüber den Skripten von SysVinit. (Abbildung 4 und**5)

Abbildung 4: Das Init-Skript des Automounters AutoFS ist eines der kürzeren Skripte unter SysVinit, ist aber trotzdem für Laien in der Regel zu unübersichtlich.

Abbildung 5: Unter Systemd ist das Service-Skript für AutoFS kürzer, wirkt aufgeräumter und ist leichter zu lesen.

Bereits vor Systemd versuchten viele Distributionen wie Fedora, Debian oder Mandriva, das Init-System zu modernisieren. Dabei galten die Init-Skripte aber immer als zwingend, nur moderner wollten die Entwickler sie gestalten. Keiner dieser Versuche, die bereits kurz nach der Jahrtausendwende begannen, führte zu derart praktischen Verbesserungen, das diese genug Momentum aufbauten, um sich durchzusetzen.

Kein Erfolg

Im Herbst 2009, ein halbes Jahr vor der Vorstellung von Systemd legte Debian-Entwickler Petter Reinholdtsen ein Konzept vor, um den Boot-Prozess angesichts des immer mehr auf Events basierten Kernels daran auszurichten [4]. Sein Plan war, das bereits bei Fedora und Ubuntu benutzte Upstart so abzuändern, dass es mit /etc/inittab zusammenarbeitet.

Die Kombination beider Init-Systeme erwies sich in den folgenden Monaten jedoch als kaum umzusetzen. Debian hatte acht Jahre an der Parallelisierung der Init-Skripte gearbeitet und war nicht viel weiter als zu Beginn.

Um in dieser desolaten Situation von der Skript-basierten sequentiellen Initialisierung wegzukommen, sahen sich Poettering und seine Kollegen Init-Systeme wie Canonicals Upstart, Apples Launchd oder SMF von Solaris an. Diese setzen auf einfache, deklarative Konfigurationsdateien anstelle von unübersichtlichen Shell-Skripten. Fast hätte Upstart sich als Nachfolger von SysVinit durchgesetzt, denn Poettering sah es anfangs als die Zukunft des Init- und Dienstemanagements für Linux an.

Upstart als Ablösung?

Sein Arbeitgeber Red Hat adoptierte Upstart für Fedora und seine Enterprise-Distribution RHEL. Mit der Zeit sah Poettering aber, dass das Konzept Nachteile hatte, die er nicht gewillt war mitzutragen. Sauberer Code stand in der Praxis nicht standhafter Logik und nicht zu Ende gedachten Konzepten gegenüber.

So fehlte laut Poettering ein durchdachtes Management von Abhängigkeiten, dies lag in den Händen des jeweiligen Administrators. In einer Diskussion vom Mai 2010 versuchte Poettering die Upstart-Entwickler Scott James Remnant und Casey Dahlin ohne Erfolg von konstruktiven Anpassungen wie dem Einsatz von Cgroups zu überzeugen [5]. Diese Niederlage markiert ironischerweise den Beginn des Siegeszugs von Systemd, von dessen Idee Arbeitgeber Red Hat anfangs alles andere als überzeugt war.

Neben dem Initialisieren stand von Anfang an das Verwalten der Dienste, besonders der der unteren Ebenen, als Hauptaufgabe im Vordergrund. Systemd wollte sicherstellen, dass diese starten, wenn das System sie benötigt oder wenn der Benutzer eine bestimmte Hardware ansteckt. Zudem sollen sie auf bestimmte Änderungen der Systemdaten reagieren.

Somit ging das Konzept von Systemd bereits in den Anfängen weit über das reine Starten und Stoppen von Prozessen hinaus. Um den administrativen Aufwand beim Hot-Plugging von Geräten zu verringern und redundanten Code zu minimieren, haben die Entwickler 2012 zunächst Udev, ein Programm zum Verwalten von Gerätedateien, in Systemd integriert.

Hin zum Systemmanager

In der Folge übernahm Systemd viele weitere Bereiche, die vorher unabhängig waren. Bereits 2013 entstanden beim Bauen von Systemd rund 70 Binärdateien. Allerdings ist es bis heute so, dass Sie beim Kompilieren als auch zur Laufzeit die meisten Komponenten abwählen dürfen.

Die Basiskomponenten sind Systemd selbst, Udev und der Logging-Mechanismus Journald. Das modulare Konzept nutzen Distributoren, um ihren Anwendern, je nach Ausrichtung des Systems unterschiedliche Komponenten anzubieten.

Systemd steuert heute neben dem Booten unter anderem das Mounten und Automounten (systemd.mount), Login (systemd-logind), Namensauflösung (systemd-resolved), Netzwerkverbindungsverwaltung (systemd-networkd), Zeitsynchronisierung, Timer (systemd-timed), Lokalisierung (systemd-localed), Suspend und Resume (systemd-suspend.service), Container (systemd-nspawn, systemd-machined) und zuletzt die erweiterte Verwaltung des Home-Verzeichnisses (systemd-homed), dem LinuxUser in einer kommenden Ausgabe einen Artikel widmet. Dabei bleibt Systemd kompatibel zu den SysVinit-Skripten.

Schnelle Verbreitung

In Anbetracht der Situation vor Systemd ist es trotzt aller Diskussionen und immer noch verbreiteter Abneigung nicht überraschend, dass alle großen Distributionen und viele Derivate relativ schnell gewechselt sind. Systemd ermöglicht es immerhin, vieles beim Entwickeln zu vereinheitlichen, die Last verteilt sich auf viele Schultern, ohne dass Distributionen dabei ihre Individualität aufzugeben bräuchten. Allerdings führt es im Fall von Gnome dazu, dass die Desktop-Umgebung ohne Systemd nur noch unter großem Aufwand läuft.

Eine kürzliche Umfrage unter Systemadministratoren ergab, dass von 2771 Befragten 2355 Systemd verwendeten. Auch Phoronix fragte Ende 2019 auf Twitter nach der Akzeptanz von Systemd. Dabei votierten 42,5 Prozent, dass sie Systemd lieben, 19,2 Prozent drückten ihre Abneigung aus, während es über 38 Prozent egal war.

Gutes Zeichen

Die Zahl derer, die aus Unkenntnis oder fehlendem Interesse daran, was ein Init überhaupt ist, zur letzten Gruppe zu zählen sind, ist vermutlich noch wesentlich größer. Das spricht im Endeffekt für Systemd, denn etwas, das im Hintergrund seinen Job zufriedenstellend erledigt, braucht man nicht unbedingt zu kennen.

Allerdings gibt es eine lange Liste meist kleinerer Distributionen, die Systemd nicht verwenden und stattdessen SysVinit oder Alternativen wie OpenRC, Runit oder S6 anbieten [6]. Darunter sind Kandiaten wie der Debian-Fork Devuan, Knoppix, das seit Version 8.6 auf Systemd verzichtet, Void Linux oder Antix.

Bislang gescheitert ist im weiteren Umfeld von Systemd der Versuch, mit KDBUS oder BUS1 eine im Kernel implementierte Interprozesskommunikation zur Ablösung des im Userspace laufenden Dbus zu etablieren. In letzter Zeit hat lediglich die Alternative Dbus-Broker etwas Fahrt aufgenommen, diese läuft aber ebenfalls im Userspace und nicht im Kernel [7].

Fazit und Ausblick

Abseits des philosophischen Disputs erleichtert Systemd viele Aufgaben bei der Administration und versorgt Sie dazu mit wesentlich mehr Informationen über das System, seine Dienste und Daemons. Könnte die Software besser sein? Natürlich, aber sie ist trotzdem SysVinit meilenweit voraus.

Was etwas stört, ist die oft herablassend und arrogant wirkende Art, mit der Poettering mit gemeldeten Fehlern umgeht und diese gelegentlich zu schnell als won’t fix deklariert und schließt. Das trägt nicht zur Deeskalation bei. Oft genug sind es aber Mythen über Systemd, denen er in seinem Blog entgegentritt. Handfeste Dokumentation gibt es dagegen im Systemd-Wiki [8].

Systemd weist in die Zukunft. Distributionen wie Fedora Silverblue und Endless OS sowie Bestandteile wie Flatpak und OStree wären ohne diese Kernkomponente nicht möglich [9]. Vieles von dem, was Poettering 2014 darüber geschrieben hat, wie das Innenleben von Distributionen künftig aussehen sollte, wurde damit Realität [10]. (agr)