© dhoch-kr, photocase.com

Wenn es beim Systemstart auf jede Sekunde ankommt, erweist sich der Linux-typische Klassiker Sys-V-Init als lästiger Bremser. Entwickler von Embedded-Geräten und schlanken Spezial-Distributionen sollten Ausschau nach zeitgemäßeren Sprintern halten.

Sobald der Linux-Kernel Hardware und Treiber initialisiert hat, übergibt er die Steuerung an das Init-System (siehe Abbildung 1). In der Regel ist das »/sbin/init« als der erste Userspace-Prozess und mit der Prozess-ID 1. Falls »/sbin/init« nicht vorhanden ist, versucht der Kernel »/etc/init«, »/bin/init« und »/bin/sh« zu starten – ein Mechanismus, den aber kaum jemand benutzt.

Abbildung 1: Der Bootloader startet den Kernel und übergibt die Kontrolle dann an das Init-System.

Interaktive Bootloader, zum Beispiel Lilo, Grub und U-Boot, erlauben es übrigens, dem Kernel Aufrufe wie »init=« manuell zu übergeben. So umgeht man das reguläre Init-System und gelangt etwa durch die Angabe von »init=/bin/sh« einfach in eine interaktive Shell für Tests oder kann das System wiederherstellen.

Theoretisch kann »/sbin/init« als einfaches Skript realisiert sein, das der Reihe nach Dienste und Anwendungen startet. In der Tat machen einige Embedded-Geräte genau dies. Ein echtes, wenn auch kleines Init-Programm bringt aber funktionelle Vorteile. Es lässt sich flexibel steuern und liefert den Status der laufenden Dienste zurück. Einige Init-Skripte überwachen die Dienste sogar und starten sie bei Bedarf neu.

Egal ob Eigenkonstruktionen oder fertiges Init-System: Der Entwickler muss darauf achten, dass sich der eigentliche Init-Prozess nie beenden darf. Andernfalls würden alle abgeleiteten Prozesse streiken und auch der Linux-Kernel geriete wortwörtlich in Panik. Außerdem sollten sich Embedded-Entwickler Gedanken darüber machen, was sie mit den Ausgaben der von Init gestarten Daemons anstellen wollen (siehe Kasten “Wohin mit den Meldungen?”).

Der am häufigsten verwendete Startmechanismus unter Linux ist Sys-V-Init [1]. Der Klassiker nervt allerdings mit langen Bootzeiten und vermag auch keine Dienste zu überwachen, sodass diese bei einem Absturz oder Update nicht automatisch neu starten. Gut also, dass es eine Reihe Alternativsysteme gibt, zum Beispiel Upstart, das maßgeblich im Rahmen des Ubuntu-Projekts entwickelt wird [2]. Für eingebettete Systeme bieten sich allerdings eher Runit, Minit oder das sehr einfache Init-Skript von Busybox an. Letzteres ist vor allem dann sinnvoll, wenn das System ohnehin mit Busybox läuft. Dieser Artikel erläutert die Stärken und Schwächen der Systeme.

Der Klassiker: Sys-V-Init

Für jeden Dienst liegt ein entsprechendes Skript im Verzeichnis »/etc/init.d«, das mit den Argumenten »start«, »stop«, »status« und so weiter die jeweiligen Aktionen ausführt. In »/etc/rcRunlevel.d« definieren symbolische Links die verschiedenen Systemzustände. Typischerweise ist Runlevel 2 der normale Betrieb, Level 3 der Betrieb mit Netzwerk und Level 5 der Betrieb mit grafischer Oberfläche.

Das System wertet beim Booten die Datei »/etc/inittab« aus, um den Standard-Runlevel zu ermitteln und Dienste, zum Beispiel Benutzer-Logins, zu starten, die in jedem Fall und unabhängig von den Runleveln vorhanden sein sollen.

Sys-V-Init arbeitet alle Skripte sequenziell in alphanumerischer Reihenfolge ab; daher tragen die Skripte meist entsprechend numerische Präfixe im Namen. Die strikt sequenzielle Abfolge sowie die Vielzahl der beteiligten Shellskripte verursachen recht lange Startzeiten.

Der Spezielle: Init von Busybox

Busybox-Init [3] ist strukturell ein minimales System-V-Init, das nur die Inittab auswertet. Mehrere Runlevel kennt das Init-System nicht, sodass der Nutzer alle weiteren Dienste – meist das User-Interface und/oder IPtables – ebenfalls in der Datei »/etc/inittab« eintragen muss. Das Init-Skript von Busybox wartet nicht mit erweiterten Funktionen auf und kommt hauptsächlich auf kleinen und mit Busybox laufenden Systemen zum Einsatz – dort aber recht häufig.

Der Kooperative: Runit

Runit [4] bietet zusätzlich die Überwachung der gestarteten Dienste an. Aktionen, die das System nur einmal beim Hoch- oder Herunterfahren des Rechners ausführt, sind bei Runit in den Skripten »/etc/runit/1« (Start) und »/etc/runit/2« (Shutdown) hinterlegt. Hier sind auch Funktionen implementiert, die Dateisysteme mounten und überprüfen. Die übrigen Dienste starten parallel dazu.

Verzeichnisse im Ordner »/etc/sv« definieren diese Services über so genannte »run«-Skripte, die auch Abhängigkeiten enthalten. Für die aktiven, zu startenden Services liegen symbolische Links in »/var/service«. Außerdem überwacht »runsv« laufende Programme und startet diese auch neu, falls jemand sie beendet hat oder sie sich selbst.

Das Runit-Tool »svn« ist für das manuelle Starten und die Statusabfrage zuständig. Mit den Argumenten »start«, »restart« und »stop« kontrolliert es die Dienste, also beispielsweise:

sv start apache

Wer etwas über den Zustand des Dienstes erfahren will, benutzt das Kommando »sv status apache«.

Runit zeigt sich übrigens kooperativ und arbeitet mit anderen Init-Systemen zusammen. So ist es möglich, mit Runit die Dienste zu überwachen und die anderen Aufgaben Busybox- oder Sys-V-Init zu übertragen. Das Kommando zum Starten der Runit-Dienste ist:

SV:123456:respawn:/sbin/runsvdir-start

Es gehört – jedenfalls in diesem Fall – in die Datei »/etc/inittab«.

Der Zeitgleiche: Minit

Minit [5] ist sehr klein und dennoch ein funktionales Init-System. Sein Erfinder Felix von Leitner, auch Autor der Dietlibc, hat dafür gesorgt, dass Minit nicht wie Sys-V-Init Unix-Domain-Sockets (»/dev/initctl«) benötigt oder wie Runit Schreibzugriff auf die Dateien in »/etc« für »/etc/runit/stopit« und die »./supervise«-Unterverzeichnisse. Es verwendet zur Kommunikation die zwei Fifos »/etc/minit/in« und »/etc/minit/out«.

Minit definiert die Services durch Verzeichnisse in »/etc/minit/«. Diese enthalten je ein »run«-Skript sowie optional »params«-, »depends«- und »respawn«-Dateien. Das »run«-Skript ist entweder eigenständig oder ein Symlink auf das auszuführende Programm. Die Datei »params« definiert die Argumente, mit denen das Programm starten soll.

Die Datei »depends« listet die Abhängigkeiten zeilenweise auf. Minit startet standardmäßig den Dienst »default«, der wiederum in der »depends«-Datei alle zu startenden Dienste definiert. Der ganze Mechanismus startet nach Möglichkeit alle Abhängigkeiten parallel, was dabei hilft, die Bootzeit zu verkürzen. Sofern die Datei »respawn« vorhanden ist, startet Minit einen Dienst nach dem Beenden auch automatisch neu.

Drei zur Wahl

Das klassische Sys-V-Init auf einem kleinen Gerät oder einer Mini-Distribution einzusetzen, die beide auf schnelles Hochfahren angewiesen sind, ist keine gute Idee. Wer Busybox sowieso schon an Bord und wenig Ansprüche an das Init-System hat, macht mit dem minimalistischem Busybox-Init meist nichts falsch. Für höhere Ansprüche – kurze Bootzeiten oder Überwachung und Neustart der Dienste – findet der Entwickler in Runit und Minit Systeme, die wesentlich mehr bieten, muss aber im Vergleich zu Standard-Linuxen beim Konfigurieren etwas umdenken. (Heike Jurzik/jk)