Obwohl systemd nun schon seit einem Jahrzehnt existiert, ist es in der Linux-Community weiterhin ein umstrittenes Thema. Trotz seiner Verwendung in zahlreichen großen Linux-Distributionen hat der Widerstand gegen systemd nicht nachgelassen.
Der Ablauf des Linux-Starts
Wenn ein Computer gestartet wird, erfolgt zunächst der Hardware-Boot. Anschließend, abhängig vom verwendeten Bootsektor, wird entweder der Master Boot Record (MBR) oder die Unified Extensible Firmware Interface (UEFI) ausgeführt. Der letzte Schritt in diesem Prozess ist das Laden des Linux-Kernels.
Der Kernel wird in den Speicher geladen, entpackt sich selbst und wird initialisiert. Ein temporäres Dateisystem, meist durch ein Programm namens initramfs oder initrd, wird im RAM erzeugt. Dieses Dateisystem ermöglicht die Erkennung und das Laden benötigter Treiber. Daraufhin kann das Userspace-Dateisystem geladen und die Userspace-Umgebung vorbereitet werden.
Die Erstellung der Userspace-Umgebung wird vom init-Prozess übernommen. Dieser ist der erste Prozess, den der Kernel im Userspace startet und hat eine Prozess-ID (PID) von 1. Alle anderen Prozesse sind entweder direkte oder indirekte Nachkommen des init-Prozesses.
Vor systemd war die gebräuchlichste Standardmethode für den Init-Prozess eine Anpassung des Unix System V Initialisierungssystems. Zwar gab es auch andere Optionen, doch System V init war die Standardwahl in den meisten Distributionen, die nicht von Berkeley Software Distribution (BSD) abstammten. Viele sehen es als „offizielle Methode“ an, da es direkt von System V Unix – dem spirituellen Vorläufer von Linux – stammt.
Der Init-Prozess startet alle Daemons und Dienste, die für ein funktionsfähiges und interaktives Betriebssystem notwendig sind. Diese Daemons verwalten Funktionen wie den Netzwerk-Stack, die Aktivierung von Hardware und die Anzeige eines Startbildschirms.
Viele dieser Hintergrundprozesse laufen nach dem Start kontinuierlich weiter. Sie können beispielsweise Ereignisdaten protokollieren, auf Hardware-Änderungen bei Geräten reagieren und Benutzeranmeldungen verwalten. Daher ist es nicht überraschend, dass das Init-System auch Funktionen zur Diensteverwaltung beinhaltet.
Mit dem Befehl ps können wir den Prozess mit der PID 1 anzeigen. Die Optionen -f (vollständige Formatliste) und -p (PID) werden verwendet:
ps -fp 1
Wie man sieht, ist der Prozess mit der PID 1 systemd. Die Ausführung des gleichen Befehls unter Manjaro Linux führte jedoch zu einem anderen Ergebnis. Der Prozess mit der PID 1 wurde als /sbin/init identifiziert. Eine kurze Überprüfung dieser Datei zeigt, dass es sich um einen symbolischen Link zu systemd handelt:
ps -fp 1
ls -hl /sbin/init
Mithilfe der Option ppid (Parent Process ID) mit ps können wir anzeigen, welche Prozesse direkt von systemd gestartet wurden:
ps -f --ppid 1
Wie in der nachfolgenden Grafik zu sehen ist, ist die Liste ziemlich umfangreich.
Die Alternativen
Es gab zahlreiche Projekte, die versuchten, eine Alternative zum traditionellen System V init zu entwickeln. Eines der Hauptprobleme bei System V init ist, dass alle Prozesse sequenziell, einer nach dem anderen, gestartet werden. Zur Effizienzsteigerung der Boot-Sequenz verwenden viele alternative Projekte die Parallelisierung, um Prozesse gleichzeitig und asynchron zu starten.
Hier sind einige Details zu einigen dieser Alternativen:
Upstart: Wurde von Canonical entwickelt und in Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 und Fedora 9 verwendet.
runit: Wird auf FreeBSD und anderen BSD-Derivaten, macOS und Solaris sowie Linux-Systemen verwendet. Es ist auch das Standard-Init-System auf Void Linux.
s6-linux-init: Diese Alternative zu System V init ist darauf ausgerichtet, sich eng an die Unix-Philosophie zu halten, die oft mit „mache eine Sache, und mache sie gut“ zusammengefasst wird.
Es gibt noch viele andere mit unterschiedlichen Funktionalitäten und Designs. Jedoch hat keiner von ihnen so viel Aufsehen erregt wie systemd.
Der systemd-Ansatz
systemd wurde im Jahr 2010 veröffentlicht und 2011 in Fedora eingeführt. Seitdem wurde es von vielen Distributionen übernommen. Es wurde von Lennart Poettering und Kay Sievers, zwei Softwareingenieuren bei Red Hat, entwickelt.
systemd ist mehr als nur ein Ersatz für init. Es handelt sich vielmehr um eine Sammlung von etwa 70 Binärdateien, die die Systeminitialisierung, Daemons und Dienste, Protokollierung und Journaling sowie viele andere Funktionen übernehmen, die zuvor von dedizierten Modulen in Linux abgewickelt wurden. Der Großteil davon hat nichts mit der Systeminitialisierung zu tun.
Einige der von systemd bereitgestellten Daemons sind:
systemd-udevd: Verwaltet physische Geräte.
systemd-logind: Verwaltet Benutzeranmeldungen.
systemd-resolved: Bietet Namensauflösung für lokale Anwendungen.
systemd-networkd: Verwaltet und erkennt Netzwerkgeräte und deren Konfigurationen.
systemd-tmpfiles: Erstellt, löscht und bereinigt flüchtige und temporäre Dateien und Verzeichnisse.
systemd-localed: Verwaltet die Systemsprachen-Einstellungen.
systemd-machined: Erkennt und überwacht virtuelle Maschinen und Container.
systemd-nspawn: Kann einen Befehl oder Prozess in einem leichtgewichtigen Namespace-Container starten und bietet ähnliche Funktionen wie chroot.
Und das ist nur die Spitze des Eisbergs, was gleichzeitig der Knackpunkt ist. Systemd hat die Anforderungen an ein Init-System bei Weitem überschritten, was seine Gegner als Inbegriff von Scope Creep bezeichnen.
„Es ist zu groß. Es macht zu viel.“
Gegner von systemd weisen auf die große und vielfältige Mischung von Funktionen hin, die es umfasst. All diese Funktionen waren bereits in Linux vorhanden, und einige davon hätten möglicherweise eine Überarbeitung oder einen neuen Ansatz verdient. Die Zusammenfassung all dieser Funktionen in einem vermeintlichen Init-System wird jedoch als architektonisch fragwürdig angesehen.
systemd wurde als Single Point of Failure für zu viele kritische Funktionen bezeichnet, was jedoch nicht gerechtfertigt erscheint. Es widerspricht zwar der Unix-Philosophie, kleine, zusammenarbeitende Tools zu entwickeln, anstatt großer Software, die alles aus einer Hand erledigt. Obwohl systemd nicht monolithisch ist (es besteht aus vielen Binärdateien und nicht aus einer einzigen großen), vereint es viele verschiedene Verwaltungstools und Befehle unter einem Dach.
Obwohl es nicht monolithisch ist, ist es groß. Um eine Vorstellung von der Größe zu bekommen, haben wir die Textzeilen im Code des Kernels 5.6.15 und im Master-Branch von systemd im GitHub-Repository gezählt.
Dies war eine relativ grobe Metrik, die Textzeilen und nicht nur Codezeilen zählte. Dies umfasste also Kommentare, Dokumentation und alles andere. Es war jedoch ein fairer Vergleich, der uns einen einfachen Maßstab lieferte:
( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l
Der Kernel hatte fast 28 Millionen (genau 27.784.340) Textzeilen. Im Vergleich dazu hatte systemd 1.349.969, also fast 1,4 Millionen. Nach unserer groben Messung macht systemd etwa 5 Prozent der Größe des Kernels aus, was beachtlich ist!
Zum weiteren Vergleich: Eine moderne Implementierung von System V init für die Arch Linux-Distribution ergab eine Anzahl von 1.721 Zeilen.
Poettering hat sich offensichtlich nicht an die Vorgaben des Institute of Electrical and Electronics Engineers (IEEE) Computer Society oder den Portable Operating System Interface (POSIX)-Standard gehalten. Tatsächlich hat er Entwickler sogar dazu ermutigt, POSIX zu ignorieren:
„Besorgen Sie sich also eine Kopie des Linux Programming Interface, ignorieren Sie alles, was darin über POSIX-Kompatibilität steht, und schreiben Sie Ihre großartige Linux-Software. Es ist sehr befreiend!“
Es gab Behauptungen, dass systemd ein Red-Hat-Projekt ist, das nur Red Hat zugute kommt, aber der Rest der Linux-Welt wird gezwungen, es zu übernehmen. Zwar wurde es innerhalb von Red Hat geboren und wird von Red Hat geführt und kontrolliert, aber von den 1.321 Mitwirkenden arbeitet nur ein Bruchteil für Red Hat.
Welche Vorteile hat Red Hat davon?
Jim Whitehurst, der Präsident von IBM und ehemaliger CEO von Red Hat, sagte einmal:
„Red Hat hat viele Optionen in Betracht gezogen, sogar Canonicas Upstart für Red Hat Enterprise Linux 6. Letztendlich haben wir uns für systemd entschieden, da es die beste Architektur bietet, die Erweiterbarkeit, Einfachheit, Skalierbarkeit und klar definierte Schnittstellen vereint, um die Probleme zu lösen, die wir heute sehen und für die Zukunft erwarten.“
Whitehurst erwähnte auch, dass sie auch Vorteile in eingebetteten Systemen sehen. Red Hat arbeitet mit „den größten Embedded-Anbietern der Welt zusammen, vor allem in der Telekommunikations- und Automobilindustrie, wo Stabilität und Zuverlässigkeit an erster Stelle stehen.“
Das scheinen technisch nachvollziehbare Gründe zu sein. Man kann das Bedürfnis des Unternehmens nach Zuverlässigkeit verstehen und es ist nicht unvernünftig, dass Red Hat seine eigenen Interessen verfolgt, aber sollten alle anderen diesem Beispiel folgen?
Der systemd-Kool-Aid?
Einige Gegner von systemd behaupten, dass Distributionen und Benutzer einfach blind dem Beispiel von Red Hat folgen und es übernehmen.
Doch wie der Satz „den Kool-Aid trinken“ ist auch das nicht ganz richtig. Der Satz entstand 1978, nachdem Sektenführer Jim Jones seine über 900 Anhänger zum Selbstmord zwang, indem er ihnen ein mit Zyanid versetztes, traubengeschmackhaltiges Getränk gab. Der Satz hat Kool-Aid fälschlicherweise in Verruf gebracht. Die Gruppe trank eigentlich Flavor Aid, aber Kool-Aid wurde seitdem mit dieser Situation in Verbindung gebracht.
Darüber hinaus folgen Linux-Distributionen Red Hat nicht blindlings; sie nehmen systemd nach sorgfältiger Überlegung an. Die Debatte tobte auf den Debian-Mailinglisten schon lange. Im Jahr 2014 stimmte die Community jedoch dafür, systemd als Standard-Init-System einzuführen, aber auch Alternativen zu unterstützen.
Debian ist ein wichtiges Beispiel, da es nicht von Red Hat, Fedora oder CentOS abstammt. Red Hat übt keinen Einfluss auf Debian aus. Und wie bei PID 1 hat Debian viele Nachkommen, darunter Ubuntu und seine zahlreichen Ableger.
Entscheidungen der Debian-Community haben weitreichende Auswirkungen. Sie werden auch heftig diskutiert und mit der Condorcet-Abstimmungsmethode entschieden. Die Community fällt solche Entscheidungen also nicht leichtfertig.
Im Dezember 2019 wurde erneut darüber abgestimmt sich weiterhin auf systemd zu konzentrieren und nach Alternativen zu suchen. Das ist das Gegenteil von blindem Folgen, sondern ein Lehrbuchbeispiel für Demokratie und Wahlfreiheit in der Praxis.
Die Grenzen der Wahl
Im Allgemeinen ist es nicht möglich, zu wählen, ob man systemd mit einer bestimmten Linux-Distribution verwenden möchte. Stattdessen entscheiden die Distributionen selbst, ob sie es verwenden möchten, und man kann wählen, welche Linux-Distribution man bevorzugt. Es kann vorkommen, dass eine geliebte Linux-Distribution auf systemd umgestiegen ist. Dies kann schockierend sein, wie wenn ein Lieblingsmusiker sein Genre wechselt.
Benutzer, die Debian, Fedora, CentOS, Ubuntu, Arch, Solus und openSUSE verwenden, und die die Einführung von systemd ablehnen, könnten das Gefühl haben, ihre bevorzugte Distribution nicht mehr verwenden zu können. Wenn die Argumente in Bezug auf die Architektur, die übermäßige Funktionalität oder die Missachtung von POSIX stark genug sind, kann es unhaltbar erscheinen, diese Distribution weiter zu nutzen.
Es gibt natürlich ein Spektrum. Auf der einen Seite stehen die Leute, die die Probleme nicht verstehen (oder sich nicht darum kümmern), und auf der anderen Seite die vehementen Gegner. Irgendwo in der Mitte sind diejenigen, die Veränderungen nicht mögen, aber sich nicht so sehr darum kümmern, dass sie die Distribution wechseln. Aber was ist mit den Distributionsflüchtlingen, die aufgrund ihrer Präferenzen oder Prinzipien ihre gewählte Distribution nicht mehr nutzen können?
Leider ist es nicht einfach, das gewünschte Init-System zu installieren. Nicht jeder hat die technischen Fähigkeiten dazu, ganz zu schweigen von den Schwierigkeiten, die auftreten, wenn Anwendungen oder Desktop-Umgebungen wie GNOME von systemd abhängig sind.
Wie wäre es mit einem Wechsel zu einer anderen Distribution? Einige wie Devuan sind als Non-systemd-Forks von Distributionen (in diesem Fall Debian) entstanden, die systemd übernommen hatten. Die Verwendung von Devuan sollte der ursprünglichen Distribution ähnlich sein, was jedoch nicht für alle Non-systemd-Forks gilt. Wer beispielsweise Fedora verlässt und zu AntiX, Gentoo oder Slackware wechselt, wird eine völlig andere Erfahrung machen.
Es wird nicht verschwinden
Ich mag einige Aspekte von systemd (einfache und standardisierte Kontrollmechanismen für Prozesse). Ich verstehe die Gründe für einige seiner Funktionen nicht (binäre Protokolle). Ich mag auch nicht, was es mit dem Bearbeiten von Privatordnern macht (wer hat das verlangt?).
Distributionen wie Debian gehen klug vor und prüfen Alternativen, um sich Optionen offenzuhalten. Dennoch wird systemd auf lange Sicht relevant bleiben.
Verwalten Sie Linux-Computer für andere? Dann sollten Sie sich sowohl mit systemd als auch mit System V init auskennen. So können Sie Ihre Aufgaben erledigen, egal auf welches System Sie stoßen.
Verwenden Sie Linux nur zu Hause? Dann wählen Sie eine Distribution, die sowohl Ihren technischen Anforderungen als auch Ihrer Linux-Ideologie entspricht.