© mezzotint123rf, 123RF
Wem Sys-V-Init zu altbacken und Systemd zu übergriffig ist, der sollte ein paar Runden mit Runit drehen. Das Initsystem vereint Vorteile beider Welten miteinander, der Admin behält die Kontrolle.
Während eine Distribution nach der anderen zu Systemd wechselt, geraten bewährte Initsystem-Alternativen wie das zehn Jahre alte Runit [1] schnell in Vergessenheit. Kein Wunder: Systemd [2] gilt zurzeit als erfolgreichster Zehnkämpfer, weil es so viele Features in sich vereint. Es verwaltet die Control Groups (Cgroups), unterstützt D-Bus und Kernel-D-Bus, beherrscht Socket-Aktivierung und löst Console Kit ab – selbst eine grafische Konfigurationsoberfläche [3] darf nicht fehlen.
Obwohl der Anwender von einzelnen Features durchaus profitiert, wird er selten alle Möglichkeiten ausschöpfen. Wer zudem, dem aktuellen Trend folgend, mit Linux-Containern oder virtuellen Maschinen für einzelne Dienste hantiert, braucht womöglich nur die Kernfunktion eines guten Initsystems, also die Supervision von Prozessen.
Supervision
Zur Supervision gehört, dass ein Initsystem mit Prozess-ID 1 (PID) startet, um Dienste zu überwachen und im Falle eines Absturzes neu aufzurufen. Dazu muss es Signale zuverlässig zustellen und Prozesse beenden können.
Im Gegensatz zu Sys-V-Init startet Runit Dienste parallel und stellt sich gegen den traditionellen Ansatz, sie als Daemons in den Hintergrund zu verbannen. Auf diese Weise kann es sich von lästigen PID-Dateien und den damit verbundenen Unannehmlichkeiten verabschieden. Diese Dateien brauchte Sys-V-Init, um zu erahnen, ob und unter welcher Prozess-ID ein Prozess läuft. Die Methode erwies sich in der Praxis allerdings als anfällig für Race Conditions, nicht gelöschte PID-Dateien verursachen weitere Störungen.
Runits Struktur
Runit besteht aus mehreren aufeinander aufbauenden Komponenten. An unterster Stelle steht »runsv« , das einzelne Dienste startet und überwacht. Dabei helfen simple Shellskripte, die den jeweiligen Dienst (etwa »sshd« ) aufrufen. Stürzen das Shellskript und der mit ihm verbundene Dienst unvermittelt ab, startet »runsv« Letzteres neu. Ein zweites Shellskript kümmert sich bei Bedarf um das Logging und verwendet die Standardausgabe des ersten Skripts als Eingabe. Auch dieses Skript überwacht »runsv« .
An zweiter Stelle steht »runsvdir« : Wie der Name verrät, startet und überwacht es die »runsv« -Prozesse, für jeden Unterordner einen. Alternativ gibt der Admin einen Ordner an, in dem »runsvdir« nach Symlinks sucht, die auf die »runsv« -Verzeichnisse verweisen. Sie stehen typischerweise im Ordner »/service/« .
Der Admin ergänzt oder entfernt die zugehörigen Dienste, indem er die Symlinks modifiziert. Stirbt ein »runsv« -Prozess unerwartet, startet ihn »runsvdir« neu. Dem Überwachungsdienst entgeht auch nicht, wenn das »/service« -Verzeichnis plötzlich neue Unterordner anbietet oder alte fehlen. In diesem Fall startet respektive beendet er die zugehörigen »runsv« -Prozesse.
Die Hauptkomponente ist aber das »runit« -Programm selbst, das Linux mit PID 1 ausführt. Seine Aufgabe: Es fährt das System und seine Dienste hoch und wieder runter. Nach dem Start durchläuft »runit« drei Phasen (Stages):
- In Stage 1 startet es ein grundlegendes Linux-System. Es mountet und prüft Dateisysteme, richtet Konsolen ein, setzt die Systemuhr und so weiter.
- In Stage 2 befindet sich das System vom Start bis zum Ausschalten. Nur in dieser Phase nimmt es Signale (»CONT« , »INT« ) entgegen, in ihr startet gewöhnlich auch »runsvdir« .
- Stage 3 kommt ins Spiel, wenn das System runterfährt. Darin hängt Runit Dateisysteme aus, speichert die Systemuhr und so weiter.
Interessant für Admins: Sie können bei Bedarf jede Komponente einzeln verwenden. Sinn ergibt das beim Einsatz von »runsvdir« , das nicht notwendigerweise mit der Prozess-ID 1 starten muss. So kann ein Systembetreuer Runit in Verbindung mit Sys-V-Init verwenden oder eine »runsvdir« -Instanz pro Benutzer als Dienst einsetzen. Auf diese Weise verwalten die User ihre Dienste selbst.
