systemd ist 10 Jahre alt, aber die Gefühle in der Linux-Community haben sich nicht gemildert – es ist heute so spaltend wie immer. Obwohl es von vielen großen Linux-Distributionen verwendet wird, hat die harte Opposition nicht nachgelassen.
Inhaltsverzeichnis
Die Linux-Boot-Sequenz
Wenn Sie Ihren Computer einschalten, bootet die Hardware und dann (je nach Art des Bootsektor Ihr Computer verwendet) entweder die Master Boot Record (MBR) ausgeführt wird oder die Einheitliche erweiterbare Firmware-Schnittstelle (UEFI) läuft. Die letzte Aktion von beiden besteht darin, die Linux Kernel.
Der Kernel wird in den Speicher geladen, dekomprimiert sich selbst und initialisiert. EIN temporäres Dateisystem wird im RAM erstellt, normalerweise von einem Dienstprogramm namens initramfs oder initrd. Damit können die benötigten Treiber ermittelt und geladen werden. Dies wiederum ermöglicht es dem Benutzerbereichsdateisystem, zu laden und sich vorzubereiten, um die Benutzerbereichsumgebung einzurichten.
Die Erstellung der Userspace-Umgebung wird durch den init-Prozess gehandhabt, der der erste Prozess ist, der vom Kernel in einem Userspace gestartet wird. Es hat ein Prozess ID (PID) von 1. Alle anderen Prozesse sind entweder direkte oder indirekte Kinder des init-Prozesses.
Vor systemd war der Mainstream-Standard für den Init-Prozess eine Überarbeitung des Unix System V-Initialisierung. Es standen andere Optionen zur Verfügung, aber System V init war die Standardoption in den meisten Nicht-Berkeley-Softwareverteilung (BSD) abgeleitete Verteilungen. Da es direkt von System V Unix – dem spirituellen Vorfahren von Linux – stammt, betrachten es viele Leute als „die offizielle Methode“, um init zu tun.
Der Init-Prozess startet alle Dämonen und Dienste, die erforderlich sind, damit das Betriebssystem auf sinnvolle und interaktive Weise funktioniert. Diese Daemons handhaben Dinge wie den Netzwerk-Stack, aktivieren andere Hardware in Ihrem Computer und stellen einen Startbildschirm bereit.
Viele dieser Hintergrundprozesse werden nach ihrem Start weiter ausgeführt. Sie können beispielsweise Ereignisinformationen protokollieren, auf Hardwareänderungen beim Einsetzen oder Entfernen von Geräten achten und Benutzeranmeldungen verwalten. Es überrascht nicht, dass das init-System auch Funktionen zur Verwaltung von Diensten enthält.
Wir können benutzen ps um den Prozess mit PID 1 anzuzeigen. Wir verwenden die Optionen f (Vollformatauflistung) und p (PID):
ps -fp 1
Wir sehen, dass der Prozess mit PID 1 systemd ist. Das Ausführen desselben Befehls unter Manjaro Linux führte zu einem anderen Ergebnis. Der Prozess mit PID 1 wurde als /sbin/init identifiziert. Ein kurzer Blick auf diese Datei zeigt, dass es sich um einen symbolischen Link zu systemd handelt:
ps -fp 1
ls -hl /sbin/init
Mit der Option ppid (Elternprozess-ID) mit ps können wir sehen, welche Prozesse direkt von systemd gestartet wurden:
ps -f --ppid 1
Es ist eine ziemlich lange Liste, wie Sie im Bild unten sehen können.
Die Alternativen
Mehrere Projekte haben versucht, eine Alternative zum traditionellen System V init zu entwickeln. Eines der Hauptprobleme besteht darin, dass bei System V init alle Prozesse seriell nacheinander gestartet werden. Um die Effizienz der Bootsequenz zu verbessern, verwenden viele alternative Projekte Parallelität, um Prozesse gleichzeitig und asynchron zu starten.
Hier sind einige Informationen zu einigen davon:
Emporkömmling: Entwickelt von Kanonisch, es wurde in Ubuntu 9.10 verwendet, roter Hut, Red Hat Enterprise Linux (RHEL) 6, CentOS 6, und Fedora 9.
Starte es: Läuft auf FreeBSD und andere BSD-Derivate, macOS und Solaris, sowie Linux-Systeme. Es ist auch das Standard-Init-System an Leere Linux.
s6-linux-init: Dieser Ersatz für System V init wurde entwickelt, um eng an die Unix-Philosophie, die oft auf den Sound-Bite reduziert wird „mache eine Sache, und mach es gut“.
Es gibt viele andere mit unterschiedlicher Funktionalität und Design. Jedoch keiner von ihnen sorgte für Furore systemd tat.
Der systemische Weg
systemd wurde 2010 veröffentlicht und 2011 in Fedora verwendet. Seitdem wird es von vielen Distributionen übernommen. Es wurde entwickelt von Lennart Poettering und Kay Sievers, zwei Software-Ingenieure bei RedHat.
systemd ist viel mehr als ein Init-Ersatz. Vielmehr handelt es sich um eine Suite von ungefähr 70 Binärdateien, die die Systeminitialisierung, Daemons und Dienste, Protokollierung und Journaling sowie viele andere Funktionen handhaben, die bereits von dedizierten Modulen in Linux verwaltet 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 Netzwerknamensauflösung für lokale Anwendungen.
systemd-networkd: Verwaltet und erkennt Netzwerkgeräte und verwaltet Netzwerkkonfigurationen.
systemd-tmpfiles: Erstellt, löscht und bereinigt flüchtige und temporäre Dateien und Verzeichnisse.
systemd-localed: Verwaltet die Systemgebietsschemaeinstellungen.
systemd-machined: Erkennt und überwacht virtuelle Maschinen und Container.
systemd-nspawn: Kann einen Befehl oder einen anderen Prozess in einem leichtgewichtigen Namespace-Container starten und bietet eine ähnliche Funktionalität wie chroot.
Und das ist nur die Spitze des Eisbergs, die auch der Knackpunkt ist. systemd hat längst die Anforderungen an ein init-System, das laut seinen Gegnern die eigentliche Definition von Scope Creep ist, übertroffen.
„Es ist zu groß. Es tut zu viel.“
Gegner von systemd weisen auf den großen, kuriosen Funktionsmix hin, den es umfasst. All diese Funktionen waren bereits in Linux vorhanden, und vielleicht brauchten einige von ihnen eine Auffrischung oder einen neuen Ansatz. All diese Funktionen in einem angeblichen Init-System zu bündeln, ist jedoch architektonisch rätselhaft.
systemd wurde für zu viele kritische Funktionen als Single Point of Failure bezeichnet, aber dies scheint nicht zu rechtfertigen. Zugegeben, es wirft die Unix-Philosophie kleine Tools zu entwickeln, die zusammenarbeiten, anstatt große Software, die alles außerhalb des Fensters erledigt. Obwohl systemd nicht streng monolithisch ist (es besteht aus vielen Binärdateien und nicht aus einer einzigen großen), enthält 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 in der Codebasis des Kernels 5.6.15 und im systemd-Master-Zweig gezählt des GitHub-Repositorys.
Dies war eine relativ grobe Metrik. Es zählte Textzeilen, nicht nur Codezeilen. Dies beinhaltete also Kommentare, Dokumentation und alles andere. Es war jedoch ein Vergleich auf gleicher Augenhöhe und gab uns einen einfachen Maßstab:
( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l
Der Kernel hatte fast 28 Millionen (27.784.340, um genau zu sein) Textzeilen. Im Gegensatz dazu hatte systemd 1.349.969 oder fast 1,4 Millionen. Mit unserer Happy-Go-Lucky-Metrik kommt systemd auf etwa 5 Prozent der Größe des Kernels, was verrückt ist!
Als weiterer Vergleich ergab sich für eine moderne Implementierung von System V init für die Arch Linux-Distribution eine Zeilenzahl von 1.721 Zeilen.
Pöttering hat offensichtlich keine Rücksicht auf die Institut für Elektro- und Elektronikingenieure (IEEE) Computer Society, noch die Tragbare Betriebssystemschnittstelle (POSIX)-Standard. Tatsächlich ist er ermutigte Entwickler, POSIX . zu ignorieren:
„Also, besorgen Sie sich eine Kopie von The Linux Programming Interface, ignorieren Sie alles, was es über POSIX-Kompatibilität sagt, und hacken Sie Ihre erstaunliche Linux-Software weg. Es ist ziemlich entlastend!“
Es gab Anschuldigungen, dass systemd ein Red-Hat-Projekt ist, das nur Red Hat nützt, aber es wird in die breitere Linux-Welt gezwungen. Ja, es wurde innerhalb von Red Hat geboren und wird von ihm regiert und gesteuert. Von den 1.321 Mitwirkenden arbeitet jedoch nur ein Bruchteil für Red Hat.
Was sind die Vorteile von Red Hat?
Jim Whitehurst, der Präsident von IBM, der sagte einst der CEO von Red Hat:
„Red Hat hat viele verfügbare Optionen in Betracht gezogen und sogar Canonicals Upstart für Red Hat Enterprise Linux 6 verwendet. Letztendlich haben wir uns für systemd entschieden, weil es die beste Architektur ist, die die Erweiterbarkeit, Einfachheit, Skalierbarkeit und klar definierte Schnittstellen bietet, um die Probleme zu lösen, die wir sehen heute und in der Zukunft voraussehen.“
Whitehurst sagte auch, dass sie auch Vorteile in eingebetteten Systemen sehen. Red Hat arbeitet mit „den größten Embedded-Anbietern der Welt zusammen, insbesondere in der Telekommunikations- und Automobilindustrie, wo Stabilität und Zuverlässigkeit an erster Stelle stehen“.
Das scheinen technisch stichhaltige Gründe zu sein. Sie können das Bedürfnis des Unternehmens nach Verlässlichkeit verstehen, und es ist nicht unvernünftig, dass Red Hat seine eigenen Interessen im Auge behält, aber sollten alle anderen nachziehen?
Das systemd Kool-Aid trinken?
Einige Gegner von systemd sagen, dass Distributionen und die Leute einfach blind dem Beispiel von Red Hat folgen und es übernehmen.
Aber genau wie der Satz „Trinken der Kool-Aid“ ist das nicht ganz richtig. Geprägt 1978 nach Sektenführer Jim JonesEr zwang seine über 900 Anhänger, Selbstmord zu begehen, indem er eine mit Zyanid versetzte Flüssigkeit mit Traubengeschmack trank, der Satz beschämt Kool-Aid fälschlicherweise. Die Gruppe hat tatsächlich Flavor Aid getrunken, aber Kool-Aid ist seitdem von diesem Pinsel geteert.
Außerdem folgen Linux-Distributionen Red Hat nicht blindlings; sie nehmen systemd nach ernsthafter überlegung an. Die Debatte tobte am Debian Mailinglisten schon lange. Im Jahr 2014 stimmte die Community jedoch für die Einführung von systemd als Standard-Init-System, sondern um auch Alternativen zu unterstützen.
Debian ist ein wichtiges Beispiel, weil es nicht von RedHat, Fedora oder CentOS abgeleitet ist. Auf Debian wird von Red Hat keine Steuerung angewendet. Und Debian hat wie PID 1 viele Nachkommen, darunter Ubuntu und seine vielen Ableger.
Entscheidungen der Debian-Gemeinschaft sind weitreichend. Sie werden auch heftig debattiert und über die Verwendung abgestimmt die Condorcet-Abstimmungsmethode. Auch die Community trifft solche Entscheidungen nicht leicht.
Es hat im Dezember 2019 erneut abgestimmt weiter konzentrieren systemd und weiter nach Alternativen zu suchen. Das Gegenteil von blindem Folgen, dies ist eigentlich ein Lehrbuchbeispiel für Demokratie und Wahlfreiheit am Arbeitsplatz.
Die Grenzen der Wahl
Sie können im Allgemeinen nicht wählen, ob Sie systemd mit einer bestimmten Linux-Distribution verwenden möchten. Vielmehr entscheiden die Distributionen selbst, ob sie es verwenden möchten, und Sie können auswählen, welche Linux-Distribution Sie bevorzugen. Vielleicht ist eine Linux-Distribution, die Sie lieben, auf systemd umgestiegen. Wie bei einem Lieblingsmusiker, der das Genre wechselt, kann dies erschütternd sein.
Leute, die Debian verwenden, Fedora, CentOS, Ubuntu, Bogen, Solus, und openSUSE, und die sich gegen die Einführung von systemd aussprechen, könnten das Gefühl haben, dass sie die Distribution ihrer Wahl nicht mehr verwenden können. Wenn sie bei einer der Architekturentscheidungen, dem Scope Creep oder der Missachtung von POSIX stark genug sind, finden sie es möglicherweise unhaltbar, diese Distribution weiter zu verwenden.
Es gibt natürlich ein Spektrum. Auf der einen Seite stehen die Leute, die die Probleme nicht verstehen (oder sich gar nicht darum kümmern), und auf der anderen Seite die leidenschaftlichen Gegner. Irgendwo in der Mitte sind diejenigen, die Veränderungen nicht mögen, sich aber nicht genug darum kümmern, um das Schiff zu springen. Aber was ist mit den Verteilungsflüchtlingen, die aufgrund ihrer Vorlieben oder Prinzipien nicht bei ihrer gewählten Verteilung bleiben können?
Leider ist es nicht so einfach, einfach das gewünschte Init-System zu installieren. Nicht jeder hat die technische Fähigkeit dazu, ganz zu schweigen von den Schwierigkeiten, die auftreten, wenn Anwendungen oder Desktop-Umgebungen wie GNOME, haben Abhängigkeiten von systemd.
Wie wäre es mit einem Wechsel zu einer anderen Distribution? Einige wie Devuan, erschien als Nicht-Systemd-Forks von Distributionen (in diesem Fall Debian), die systemd übernommen hatten. Die Verwendung von Devuan sollte der Elterndistribution ähnlich sein, aber das ist nicht bei allen Nicht-Systemd-Forks der Fall. Wenn Sie beispielsweise Fedora verlassen und nach ziehen AntiX, Gentoo, oder Slackware, werden Sie eine ganz andere Erfahrung machen.
Es geht nirgendwo hin
Ich mag einiges von dem, was systemd macht (einfache und standardisierte Kontrollmechanismen für Prozesse). Ich verstehe die Gründe für einige seiner Funktionen (Binärprotokolle) nicht. Ich mag auch einiges von dem, was es tut (das Überarbeiten von Privatordnern – wer hat das verlangt?).
Distributionen wie Debian machen die clevere Sache und untersuchen Alternativen, um sich die Optionen offen zu halten. Systemd ist jedoch auf lange Sicht dabei.
Wenn Sie Linux-Rechner für andere verwalten, lernen Sie systemd sowie System V init kennen. Auf diese Weise können Sie Ihre Aufgaben erfüllen, egal auf welche Sie stoßen.
Verwenden Sie Linux einfach zu Hause? Wählen Sie in diesem Fall eine Distribution, die sowohl Ihren technischen Anforderungen entspricht als auch Ihre Linux-Ideologie ergänzt.