Die meisten Distributionen laufen mittlerweile mit Systemd. Andere Init-Systeme lassen sich in bestimmten Distributionen aber auch heute noch nutzen.

Die Mehrzahl der Distributionen verwendet heute Systemd als initialen Betriebssystemprozess und für viele andere Dinge. Es besteht jedoch weiter die Möglichkeit, ein Linux-System auch mit Desktop-Umgebung mit einem anderen Init-System zu betreiben. Allerdings schränkt eine solche Entscheidung die Auswahl an Distributionen ein (siehe Kasten “Init-Systeme in Distributionen”). Der Schwerpunkt dieses Artikels liegt auf Debian und Devuan, die der Autor selbst einsetzt.

Gründe für den Wechsel

Dem Autor ging es bei der Suche nach Alternativen um eine Mischung aus Unzufriedenheit mit dem Standardverhalten von Systemd, dem Umfang der im Systemd-Hauptbinärprogramm implementierten Funktionen und seiner damit verbundenen Größe im Vergleich zu SysVinit oder Runit. Weiterhin störte ihn das Verhalten einiger Systemd-Entwickler bei Antworten auf Fehlerberichte, insbesondere auch im Bezug auf Sicherheitslücken [1].

So umfasst das Systemd-Binary in /lib/systemd/systemd/ mittlerweile über 1 MByte, während /sbin/init in Devuan “Ceres” mit knapp 56 KByte auskommt und /sbin/runit gar nur mit 26 KByte. Mit der Codegröße steigt die Anzahl der wahrscheinlich enthaltenen Fehler für einen Prozess, der als PID 1 läuft. Server lassen sich mit alternativen Init-Systemen zudem ohne D-Bus betreiben, insofern es nicht andere Dienste auf dem Server erfordern.

Sicherlich lassen sich fürs Booten unkritische Dateisysteme in der /etc/fstab mit nofail markieren. Wenn Systemd im Rettungsmodus aber aufgrund eines Fehlers beim Einhängen von Dateisystemen oder dem Aktivieren des Auslagerungsspeichers keinen SSH-Dienst startet, obwohl das problemlos möglich wäre, dann stellt sich die Frage: Besitzt das formal korrekte Booten des Systems tatsächlich mehr Relevanz als das Faktum, dass es überhaupt startet [2]? Das soll an dieser Stelle genügen – verschiedene Argumente pro und kontra waren ja in der Vergangenheit oft Teil ebenso langer wie hitziger Diskussionen.

Benötigte Funktionen

Ein Überblick über die verschiedenen Init-Systeme gibt eine Orientierungshilfe zu den möglichen Alternativen. Wichtig dabei: Bei Systemd handelt es sich mittlerweile um viel mehr als nur ein Init-System. Auch laut dem Entwickler des S6-Init-Systems, Laurent Bercot, besteht ein Init-System aus mehreren Teilen. Es umfasst neben dem eigentliche Init-Programm, zum Beispiel /sbin/init, noch

• das Programm, das als PID 1 läuft,
• ein System zum Überwachen von Prozessen, sowie
• ein Programm, das Dienste verwaltet.

Es geht also darum, alles bereitzustellen, um nach dem Starten des Linux-Kerns durch den Bootloader ein lauffähiges System mit allen dazu erforderlichen Diensten zu erhalten. Konzeptionell zwar getrennt, sollten diese Teile dennoch gut zusammenarbeiten, betont Bercot. So ist das Überwachen von Prozessen eng an das Programm geknüpft, das als PID 1 läuft.

Oft kombinieren auch traditionelle Init-Systeme mehrere Funktionen in einem Binärprogramm. So vereint etwa SysVinit /sbin/init und PID 1 in einem Programm. Systemd, der Launchd von MacOS (der Lennart Poettering als Inspiration für Systemd diente) sowie Upstart implementieren alle Teile eines Init-Systems. SysVinit und OpenRC dagegen bieten nur Teile der Funktionalität. S6 besteht aus dem Programm zum Überwachen von Prozessen sowie einem Zusatzpaket für ein /sbin/init. Das Service-Management implementiert dagegen s6-rc.

Init-System austauschen

Am einfachsten gelingt der Einsatz eines anderen Init-Systems durch die Installation einer Distribution, die das unterstützt. Wie schon erwähnt, wählen Sie etwa beim Debian-Abkömmling Devuan bei der Installation das gewünschte Init-System. Devuan erlaubt es zudem, das Init-System jederzeit leicht zu wechseln, indem Sie das gewünschte Paket nachträglich installieren (siehe Tabelle “Debian/Devuan: Init-Systeme”).

Eine weitere Möglichkeit besteht im Wechsel von Debian zur entsprechenden Devuan-Version. Dazu gibt es auf der Devuan-Seite entsprechende Anleitungen. Das Vorgehen sieht den Austausch der entsprechenden Paketquellen in /etc/apt/sources.list vor. Danach gilt es, je nach Debian-Version ein bestimmtes Paket zu installieren.

Für den Wechsel von Debian “Buster” auf Devuan “Beowulf” etwa benötigen Sie das Paket eudev; das Paket für das gewünschte Init-System geben Sie gleich mit an. Nach einem Neustart lässt sich Systemd dann entfernen. Allerdings spielt auch hier eine Rolle, dass sich Systemd aus einem laufenden System nicht entfernen lassen möchte. Daher sollten Sie die Hinweise für Debian beachten. Für den Wechsel von Debian “Bullseye” auf das neue Devuan “Chimaera” gab es bei Redaktionsschluss noch keine Anleitung. Das Vorgehen dürfte aber ähnlich wie beim Vorgänger ausfallen.

Wer indes lieber Debian einsetzt, kommt um manuelle Anpassungen nicht herum. Ein guter Ansatz besteht darin, bei der Installation nach dem Schritt Software auswählen und installieren mit [Alt]+[F2] in eine Konsole zu wechseln und dort das entsprechende Init-System zu installieren. Dazu wechseln Sie mit chroot /Ziel in das zu installierende System. Das Init-System richtet beispielsweise der Aufruf apt install sysvinit-core ein. Für ein Desktop-System benötigen Sie zusätzlich libpam-elogind als Ersatz für libpam-systemd. Damit landet auch Elogind als Ersatz für Systemd-Logind auf dem System.

Der Wechsel auf ein anderes Init-System funktioniert in Debian wie in Devuan, mit einer Ausnahme: Der Umstieg von Systemd auf ein anderes Init-System erfordert zusätzliche Schritte (Abbildung 1), da das Systemd-Paket das Entfernen verweigert, wenn Systemd als PID 1 läuft (Abbildung 2). Eine gute Möglichkeit besteht darin, die erforderlichen Pakete im Single-User-Modus zu installieren. Dazu leeren Sie zunächst den Paket-Cache (Listing 1, Zeile 1), damit sich nur die erforderlichen Pakete darin befinden, und laden dann die erforderlichen Pakete und deren Abhängigkeiten herunter (Zeile 2). Dann wechseln Sie in den Single-User-Modus (Zeile 3) und installieren die Pakete aus dem Paket-Cache (Zeile 4). Zu guter Letzt starten Sie das System neu (Zeile 5).

Abbildung 1: Ganz so einfach geht es nicht: Auch nach Bestätigung der Sicherheitsabfrage im Rescue-Modus …

Abbildung 2: … verweigert Apt das Entfernen des Systemd-Pakets. Daher gilt es, die Pakete mit Dpkg zu installieren.

# apt clean
# apt install --download-only runit-init libpam-elogind
# systemctl rescue
# dpkg -i /var/cache/apt/archives/*.deb
# reboot

Der Wechsel des Init-Systems ohne Installation von Elogind, etwa für einen Server oder ein anderes System ohne Desktop-Umgebung, gelang im Test einfacher. Es genügte, das Paket für das Init-System zu installieren und das System neu zu starten. Auf einem System ohne Desktop-Umgebung genügte zum Wechsel auf OpenRC der Aufruf apt install openrc sysvinit-core, gefolgt von einem einfachen Neustart via reboot. Die während der Installation in einem Warnhinweis angegebene For-Schleife trennt das System jedoch vom Netz, bevor sie den Neustart ausführt. Bei einem Wechsel via SSH-Konsole erreichen Sie das System daher ohne einen Neustart nicht mehr.

Der Einsatz von Debian mit einem alternativen Init-System erfordert mitunter weitere Anpassungen. So entfernte der Paketbetreuer für NetworkManager das Init-Skript für den Hintergrunddienst, ohne diesen Schritt näher zu begründen [3]. Der Debian-Entwickler Matthew Vernon erstellte dankenswerterweise ein Paket namens orphan-init-scripts, das in der Version 0.07 neben diesem Init-Skript auch noch Skripte für den Intel Wireless Daemon (iwd), GPSD (gpsd), Nftables (nftables), den 389 Directory Server (dirsrv) sowie zwei weitere Pakete enthält.

Die Hinweise in dem Artikel basieren auf einer Anleitung [4], die Matthew Vernon für die Release Notes [5] und die Installationshinweise [6] für Debian “Bullseye” vorschlug. Er dokumentierte das auch im Debian Wiki [7]. Der kurze Absatz 2.2.10 in den Veröffentlichungshinweisen verweist darauf.

Dem Autor standen diese Hinweise zum Zeitpunkt seines Wechsels auf alternative Init-Systeme noch nicht zur Verfügung. Der Umstieg auf SysVinit in Debian und der entsprechenden Devuan-Version gelang mit etwas Erfahrung im Bezug auf das Paketmanagement via Apt dennoch. In einem Fall führte das jedoch durch den Wechsel auf Elogind zur Deinstallation vieler Desktop-Pakete. Diese ließen sich jedoch nachträglich wieder einrichten. Wobei Sie beim Verwenden anderer Init-System noch achten sollten, erklärt der Kasten “Vorsicht, Falle!”.

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:ff", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="en0"

SysVinit

SysVinit gilt als Urgestein unter den Init-Systemen. Bis Debian 6 war es das einzige offiziell unterstützte Init-System, ab Debian 7 kam Systemd als Vorschau hinzu, seit Debian 8 gilt Systemd als Standard. Auch in anderen Distributionen war SysVinit lange Zeit Standard.

SysVinit besteht aus dem Init-Programm /sbin/init mit der PID 1, das anhand der Konfiguration in /etc/inittab ein Skript mit dem Runlevel als Argument aufruft. Passend zum jeweiligen Runlevel lädt es weitere Skripte unterhalb von /etc/init.d/ mit dem Argument start oder stop nach. Um welche Skripte es sich handelt, ergibt sich aus den Symlinks unterhalb con /etc/rcRunlevel.d.

Das lief lange Zeit sequenziell, bis das von Suse eingeführte insserv auch in Debian für einen abhängigkeitsbasierten parallelen Start von Init-Skripten zum Einsatz kam. Über init-d-script bietet Debian gar einen deklarativen Ansatz für Init-Skripte, wo für Standardfälle die Definition einiger Variablen genügt, um einen Dienst zu verwalten. Zusätzlich dazu startet Init über die Inittab auch die typischen TTY-Konsolen.

Runlevel wechseln Sie mit init Runlevel, den aktuellen zeigt who -r an. Runlevel 0 schaltet das System aus, 6 startet das System neu. Der Runlevel 1 fährt das System in den Single-User-Mode. Die Mehrbenutzer-Runlevel 2, 3 und 5 differenziert Debian nicht näher, Runlevel 4 kommt nicht zum Einsatz.

Dienste rufen Sie mit /etc/init.d/Skript start auf. Als weitere Aktionen stehen stop für das Anhalten und status für die Statusanzeige eines Diensts zur Verfügung. Das Ausführen des Skripts ohne Argument zeigt in der Regel die verfügbaren Aktionen.

Der Befehl insserv Skript hängt ein Skript in das Init-System ein, das Entfernen gelingt mit insserv -r. Standardmäßig verarbeitet Insserv dazu den Bereich INIT INFO im jeweiligen Init-Skript. Mit einem Trick lässt sich das erneute Einhängen bei einer Aktualisierung des Pakets verhindern:

insserv Skript,stop=0,1,2,3,4,5,6,S

Die tatsächliche Startreihenfolge schreibt Insserv in die Dateien /etc/init.d/.depend*, die es mithilfe von startpar in einer Makefile-ähnlichen Weise abarbeitet. Als weiteres Werkzeug zum Verwalten der Symlinks dient update-rc.d.

OpenRC

OpenRC setzt auf SysVinit auf, verwendet optional aber auch das eigene openrc-init als ersten Prozess des Systems. Da das Init vom OpenRC die Datei /etc/inittab nicht auswertet, gilt es dann jedoch, die üblichen TTY-Konsolen anderweitig zu starten. In Zusammenhang mit Sysvinit hängt sich OpenRC je nach Distribution entweder direkt über die /etc/inittab oder das von dort für die Runlevel aufgerufene Skript /etc/init.d/rc in SysVinit ein. Im Rahmen des Artikels kommt OpenRC mit SysVinit zum Einsatz.

Im modular aufgebauten OpenRC gesellt sich dem Init-Prozess openrc hinzu, das je nach Runlevel Dienste startet und stoppt. Es ersetzt das rc-Skript von SysVinit und beendet sich nach dem Starten aller Dienste. Es gibt dabei auch einen parallelen, in der Grundeinstellung deaktivierten Modus, der jedoch zuweilen Probleme verursacht. Optional überwacht supervise-daemon einen Dienst. In Debian-artigen Distributionen verwendet OpenRC in der Regel jedoch die üblichen Init-Skripte. Optional lassen sich sogar Runit [8] oder S6 [9] für die Überwachung von Diensten verwenden.

Der Befehl rc-status zeigt Informationen über den Status der Dienste in den verschiedenen Runleveln. Die Status tragen in OpenRC Namen wie off, boot, default, sysinit und recovery. Eine Liste erhalten Sie mit rc-status -l. Ohne Parameter liefert der Befehl eine Übersicht der laufenden Dienste und deren Status. Mit einer gleichnamigen Datei in /etc/conf.d lassen sich zudem dem betreffenden Init- oder Run-Skript Parameter übergeben.

Analog zu systemctl --state=failed liefert openrc -c oder openrc --crashed eine Liste nicht richtig gestarteter Dienste. Ohne die Überwachung für einen Dienst via supervise-daemon bekommt OpenRC jedoch nicht mit, ob der Dienst noch läuft. Es bemerkt also etwa das harte Stoppen des Prozesses für den Cron-Dienst nicht.

Die einzelnen Dienste lassen sich mit rc-service verwalten; eine Liste gibt rc-service -l aus. Der Befehl rc-service Dienst status zeigt den Status eines Diensts an, rc-service Dienst start startet ihn. Auch hier zeigt rc-service Dienst ohne Aktion die weiteren verfügbaren Aktionen.

Zu welchen Runleveln die einzelnen Dienste gehören, lässt sich mit rc-update beeinflussen. So fügt rc-update add Dienst Runlevel einen Dienst einem Runlevel hinzu. Ohne dessen Angabe nutzt es den aktuellen Runlevel, üblicherweise default, wie ihn auch rc-status anzeigt. Einen Überblick, welche Dienste zu welchen Runleveln gehören, fördert rc-update show zutage. Analog dazu entfernt rc-update delete einen Dienst aus einem Runlevel.

Die globalen OpenRC-Einstellungen befinden sich bei Debian-artigen Distributionen in /etc/rc.conf. Hier lässt sich der parallele Start der Dienste aktivieren. Zudem gibt es viele weitere Funktionen, die man bei Bedarf zuschalten kann.

Über die Variable rc_ulimit setzten Sie in OpenRC Ulimit-Parameter. Viele Init-Skripte verwenden den von Debian bekannten Befehl start-stop-daemon, für den sich in der Konfiguration ebenfalls Parameter angeben lassen, etwa ein gewünschter Nice-Wert. Auch nutzt OpenRC optional Cgroup v1 und v2.

OpenRC bringt sogar einen eigenen Interpreter für sogenannte Run-Skripte mit. Er heißt je nach Distribution runscript oder openrc-run. Ein Beispiel für ein Skript, das diesen Interpreter verwendet, ist /etc/init.d/savecache: Es schreibt die Caches von OpenRC auf nicht flüchtige Speicher.

Einen guten Überblick über OpenRC liefert das Gentoo-Wiki [10], daneben empfiehlt sich die Lektüre des OpenRC Users Guide [11].

Runit

Runit dient als kleines, modulares und portables System zum Verwalten von Diensten. Es überwacht automatisch, ob Dienste noch laufen. Dazu startet der Befehl runsvdir für einen in einem Verzeichnis vorhandenen Dienst den Befehl runsv, der den Dienst startet und überwacht. Üblicherweise handelt es sich dabei um ein Verzeichnis mit Symlinks auf die aktuellen Dienste.

Jeder Dienst befindet sich in einem Verzeichnis mit einer bestimmten Struktur, zusammen mit dem essenziellen Skript run. Es enthält alle Befehle, um den Dienst zu starten. Dazu gehört auch das Starten anderer Dienste, die der entsprechende Dienst voraussetzt. Der letzte Befehl eines solches Skriptes lautet in der Regel exec und ersetzt den Shell-Prozess, der das Skript ausführt, durch den Prozess des eigentlichen Diensts. Da dieser als Kind-Prozess von runsv läuft, bekommt Runit jederzeit mit, ob er noch läuft.

Analog dazu stoppt das Skript finish den Dienst wieder. Die Protokollierung der Ausgaben des Diensts regelt das Skript run im Verzeichnis log. Je ein Symlink supervise für den Dienst und für das Protokollieren zeigt auf ein Verzeichnis, in dem Runit die Informationen zum Überwachen des Prozesses ablegt.

Für das Protokollieren der Standard- respektive Fehlerausgabe eines Diensts kommt üblicherweise der kleine Dienst svlogd zum Einsatz, der Klartextdateien schreibt. Das Ganze lässt sich bei Debian-basierten Distributionen nach der Installation von Runit mit apt install runit anhand des Verzeichnisses /etc/sv/ssh/ nachvollziehen. Das Protokoll landet bei Debian im Verzeichnis /var/log/runit/ssh/. Auf die jeweils aktuelle Protokolldatei verweist der Symlink /var/log/runit/ssh/current.

Runit kennt die drei Stages 1, 2 und 3. Für jede Stufe startet es das jeweilige Skript in /etc/runit/1, /etc/runit/2 und /etc/runit/3. Das Skript für Stage 1 startet die einmaligen Aufgaben beim Systemstart, das für Stage 2 alle Dienste für den Mehrbenutzerbetrieb, und Stage 3 fährt das System herunter. Runit führt Stage 3 aus, wenn Stage 2 ohne Fehler endet oder es den Befehl erhält, neu zu starten oder herunterzufahren.

In Debian-basierten Distributionen enthalten nur wenige Pakete für Dienste entsprechende Service-Verzeichnisse mit Run-Skripten für Runit, wie etwa openssh-server für OpenSSH und tor für Tor. Daher verwenden die Skripte für Stage 1 und 2 das Skript run_sysv_scripts, um die jeweiligen Init-Skripte zu starten, auf die Symlinks in /etc/rcS.d/ beziehungsweise /etc/rc2.d/ verweisen. Run-Skripte verwenden mitunter noch weitere Hilfsprogramme für Runit, wie chpst, das einen Prozess mit bestimmten Anpassungen am Prozesszustand startet. Es wechselt etwa dessen Eigentümer und Gruppe oder verändert Ulimit-Werte für den Prozess.

Runit lässt sich sehr flexibel in ein bestehendes System integrieren. Möchten Sie es zunächst einmal mit Systemd oder SysVinit als Prozess 1 ausprobieren, installieren Sie das Paket runit-run. Um stattdessen Runit als PID 1 zu verwenden möchte, richten Sie stattdessen runit-init ein. Nur in diesem Fall führt das Skript für Stage 2 die Init-Skripte aus /etc/rc2.d/ aus.

Der Befehl sv zeigt oder steuert den Zustand von Diensten. So zeigt sv status ssh den Status des OpenSSH-Diensts (Listing 3). Der Befehl zeigt die Prozess-ID des Sshd-Hauptprozesses, die PID des svlogd-Prozesses sowie deren Laufzeit. Das Kommando sv down ssh stoppt den Dienst, sv up ssh startet ihn wieder.

$ sv status ssh
run: ssh: (pid 27645) 170s; run: log: (pid 5295) 255606s

Des Weiteren lassen sich mit sv Signal ssh auch Signale an den Dienst schicken. Zur Auswahl stehen pause, cont, hup, alarm, interrupt, quit, 1, 2, term und kill. Einen einmaligen Start, ohne den Dienst bei Beenden automatisch neu zu starten, erledigt sv once Dienst. Üblicherweise lässt sv den Log-Dienst laufen. Dienst und Log-Dienst zusammen stoppt der Befehl sv exit ssh.

Sv bietet auch zu LSB-Init-Skripten kompatible Aktionen. So startet sv ssh start den OpenSSH-Dienst, sv ssh stop stoppt ihn wieder. Dabei wartet Sv bis zu 7 Sekunden und gibt eine Statusmeldung aus. Zu den weiteren Aktionen zählen reload und restart. Die Manpage zu Sv erläutert alle im Detail. Für das gesamte System installiert das Paket runit-init passende Symlinks für die Befehle shutdown, poweroff und reboot.

Die Webseite des Autors von Runit enthält eine gute Übersicht und eine Beschreibung der einzelnen Bestandteile von Unix [12]. Die Anleitungen entsprechen jedoch teilweise nicht mehr dem Stand der Zeit. Daher empfehlen wir, stets auch die Manpages des Systems zu Rate zu ziehen, auf dem Runit läuft.

Beispiele für Run-Skripte für viele Dienste finden Sie in der Sammlung des Runit-Autors [13]. Diese oft etwas älteren Beispiele kommen aus verschiedenen Unix-Systemen und laufen unter Debian gelegentlich nicht ohne Anpassungen.

Weitere Alternativen

Die Welt der Init-Systeme ist noch weit größer. So gibt es als Alternative zu Runit auch noch S6, für das ein gleichnamiges Debian-Paket bereitsteht. Der Fokus von S6 liegt auf dem Überwachen von Prozessen. Das Zusatzprogramm s6-linux-init ermöglicht, S6 auch als Init-System einzusetzen, doch fehlt dafür in Debian bislang ein Paket.

Allerdings arbeitet der Autor an dem ambitionierten Projekt, auf Basis von S6 den idealen Service-Manager zu entwickeln. Nach Ansicht des Autors bildet ein solcher das letzte noch fehlende Teil einer vollständigen Alternative zu Systemd.

Ein weiteres Init-System nennt sich GNU Sheperd [14] und kommt in GNU Guix zum Einsatz. Es handelt sich dabei um einen Service-Manager für eine Herde von Diensten, der die entsprechende Funktionalität in SysVinit oder anderen Init-Systemen ersetzen soll.

Einer für alle

Unabhängig vom verwendeten Init-System lassen sich Dienste mit Befehl service Dienst Aktion verwalten. So startet auf Debian-artigen Systemen der Befehl service start ssh den OpenSSH-Server. Weitere gängige Aktionen sind stop, restart und status. Eine Liste der Aktionen zeigt service Dienst ohne Aktion. Der Befehl ruft mit SysVinit das entsprechende Init-Skript mit der Aktion als Argument auf, andere Init-Systeme leiten die Anfrage entsprechend weiter.

Fazit

Die verschiedenen Init-Systeme lassen sich vor allem in Devuan, aber auch in Debian und einigen anderen Distributionen durchaus sinnvoll nutzen. Mithilfe von Elogind laufen auch Desktop-Systeme damit gut. Wer Devuan oder eine andere Distribution einsetzt, die Init-Alternativen unterstützt, geht den leichten Weg. Schwieriger, in Debian jedoch weiterhin möglich, gestaltet sich der Umstieg innerhalb eines Systemd-basierten Systems. Manche Distributionen lassen sich ohne größeren Aufwand nicht mehr ohne Systemd betreiben. Support fällt in einem solchen Fall ebenfalls flach.

Wer indes einmal ein anderes Init-System nutzt, bemerkt in der Praxis sowohl im Desktop-Betrieb als auch bei der Administration von Servern kaum Unterschiede. Das Verwalten der Dienste unterscheidet sich allerdings. Laufen sie wie vorgesehen, kümmert es weder ein OpenSSH noch eine Plasma-Desktop-Sitzung, was darunter läuft. Hier und da fehlt jedoch eine Funktion, die auf Systemd zurückgreift.

So setzt Plasma in Sachen Verfügbarkeit mittlerweile Systemd zum Starten von Hintergrunddiensten ein, läuft jedoch weiterhin auch ohne. Auch in Bezug auf die Boot-Geschwindigkeit fielen mit SysVinit und Runit zumindest bei SSD-basierten Systemen im Test keine wesentlichen Unterschiede auf. Da für OpenRC und Runit nur für wenige Dienste native Anpassungen vorliegen, verwenden diese (wie anfangs auch Systemd) die entsprechenden SysVinit-Init-Skripte. (tle/jlu)