Warum wird Systemd eigentlich gerne schlechtgeredet?

Die Einführung von Systemd war für so einige Linux-Enthusiasten ein vollkommener Umbau von Linux, absolut böse – die Reiter der Apokalypse kommen.

Grundlegend war Systemd zu Beginn nur für den Start der Dienste unter Linux zuständig – also um ein lauffähiges System zu bekommen. Davor wurde jeder Dienst einzeln gestartet. Dies dauerte natürlich so seine Zeit, Systemd startet hingegen mehrere Dienste zur selben Zeit. Schnell wurden Systemd jedoch mehrere Funktionen hinzugefügt – etwa die Verwaltung der Logs, man kann damit sein System automatisieren und vieles mehr.

Warum bezeichnen manche Systemd nun als böse?

Unter Linux herrscht seit jeher die Philosophie „One task – one tool“ – also für eine Aufgabe ein Werkzeug. Systemd hingegen verwaltet nicht nur eine einzige Aufgabe, sondern viele. Noch dazu kommt: Systemd legt die Logs in binäre Dateien statt in reine Textdateien – man kann also etwa keinen einfachen Texteditor nutzen, um in diese Einblick zu erhalten. Böse, sehr böse.

Aber Systemd ist reine freie Software, deshalb auch im Quellcode verfügbar. Systemd ist nicht böse, weil es so viele undokumentierte Funktionen geben würde – sondern weil wohl nur der Red-Hat-Entwickler Poettering wirklich versteht, was Systemd alles kann und wie es dies tut. Heute haben wir unter Linux mit Systemd ein einfach zu handhabendes Werkzeug für viele Dinge.

Nach der Theorie noch ein wenig Technik

Hinter Systemd stecken nicht nur die services – also die zu verwaltenden Dienste -, sondern auch die sockets – interne Netzwerkverbindungen zwischen den Diensten – und die targets. Targets sind die Ziele, die mit Systemd zu erreichen sind – also Zustände des Systems, die erreicht werden sollen.

Unter dem vorangegangenen Link finden Sie weitere Informationen, hier sehen wir uns etwas mehr die Theorie an, um zu verstehen, wie die Technik dahinter funktioniert. Lassen wir uns beispielsweise einmal anzeigen, was hinter den Targets steckt. Es gibt etwa das Target reboot.target – es startet das Betriebssystem, den Computer, neu. Um uns die einzelnen Services dahinter anzusehen, nutzen wir den Befehl systemctl mit der Option list-dependencies und dem gewünschten Target:

systemctl list-dependencies reboot.target

Um reboot.target auszuführen, sind also folgende Services auszuführen:

• plymouth-reboot.service – grafische Oberfläche für den Start, Shutdown (Logo, Fortschrittsbalken …)
• plymouth-switch-root-initramfs.service – die initiale Start-Datei
• systemd-reboot.service – Systemd neu starten

Für das graphical.target – also das Standard-System mit grafischer Oberfläche – sind schon einige Services mehr nötig:

systemctl list-dependencies graphical.target

Die in der Auflistung aufgeführten services, mounts, targets und sockets müssen also gestartet und auch heruntergefahren werden. Je nach installierten Diensten – etwa mit der Datenbank MariaDB mariadb.service – können es mehr oder weniger sein. Mit:

systemctl --type=target --all

können wir uns alle auf dem System vorhandenen Targets anzeigen lassen:

In der Auflistung finden wir unter anderem etwa auch das Target rescue.target – in der tabellarischen Ansicht finden wir auch den aktuellen Status und natürlich eine kurze Beschreibung. Das rescue.target schleudert das System natürlich in den Rettungsmodus. Mit der Option isolate können wir in ein beliebiges Target wechseln – dies ist natürlich in diesem Beispiel nicht förderlich (Sie schießen damit alle laufenden Anwendungen ab und wechseln in den Rettungsmodus auf das Terminal):

systemctl isolate rescue.target

Jetzt können wir natürlich auch einen Standard-Modus festlegen – das System startet dann automatisch in diesem Modus. Hierzu dient die Option set-default – wollen wir einmal standardmässig in den Modus ohne grafische Oberfläche starten, dann so

systemctl set-default multi-user.target

Beim nächsten Neustart würde das System ohne grafische Oberfläche direkt in das Terminal booten. Um wieder in die grafische Oberfläche zu starten:

systemctl set-default graphical.target

Natürlich können Sie auch aus dem System ohne grafische Oberfläche direkt in die grafische Oberfläche starten, ohne das komplette System neu zu starten:

systemctl isolate graphical.target

6