Upstart und Systemd – gleich zwei neue Ansätze konkurrieren um die Pole-Position beim Linux-Start. Wir unterziehen die Kandidaten einem konzeptionellen Vergleich.

Der Linux-Kernel übergibt nach seinem Start die Kontrolle an das kleine Programm Init. Ihm kommt wiederum die Aufgabe zu, alle für den Betrieb notwendigen Dienste zu starten und die Hardware einzurichten. In der Vergangenheit werkelte in den meisten Distributionen ein sogenanntes SysV-Init, das alle Systemdienste strikt nacheinander anschiebt. Da die Distributionen jedoch immer mehr Programme und Dienste mitbringen, dauert es immer länger, bis der Anwender endlich vor seinem Desktop sitzt.

Damit aber nicht genug: Während SysV-Init etwa eine angestöpselte Festplatte initialisiert und einbindet, wartet der gesamte Rest des System auf diese eine Hardwarekomponente. Tritt hierbei ein Problem auf, stoppt dies den kompletten Bootvorgang.

Apropos Absturz: Um festzustellen, ob ein essenzieller Dienst noch läuft oder als Zombie durch den Hauptspeicher geistert, stellt SysV-Init einige Verrenkungen an – in der Regel überwacht es die vom Daemon unter /var/run in einer Datei hinterlegte Prozess-Nummer (PID). Abschließend unterscheidet SysV-Init noch mehrere recht starre Systemkonfigurationen, die sogenannten Runlevel [1].

Emporkömmling

Mit diesen Problemen sahen sich zunehmend auch die Macher der Distribution Ubuntu konfrontiert. Unter ihnen war auch Scott James Remnant, der das Heft schließlich selbst in die Hand nahm und Upstart [2] entwickelte. Wie SysV-Init kommt auch Upstart in Form des Programms /sbin/init, das der Kernel automatisch als ersten Prozess mit der PID 1 startet. Damit sind die Gemeinsamkeiten allerdings schon beendet.

Anstelle stupide alle einem Runlevel zugewiesenen Dienste zu starten, wartet Upstart auf bestimmte Ereignisse, wie etwa “Netzwerk aktiviert” oder “Fernsehempfänger angeschlossen”. Sobald ein solches eintritt, führt Upstart eine oder mehrere passende Aktionen aus. Diese sogenannten Jobs wecken wiederum alle notwendigen Dienste oder richten die Hardware ein. Sämtliche Jobs sammelt Upstart im Verzeichnis /etc/init, einen Beispieljob zeigt Listing 1. Eine Liste mit allen Jobs wirft das Kommando initctl list aus (Abbildung 1).

initctl list liefert alle Jobs, deren aktuellen Zustand und – sofern bekannt – die jeweils zugehörige Prozess-ID.” width=”209″ height=”300″ /> Abbildung 1: Der Befehl initctl list liefert alle Jobs, deren aktuellen Zustand und – sofern bekannt – die jeweils zugehörige Prozess-ID.

start on filesystem
exec /usr/bin/Programm
pre-start script
  # Erstelle notwendiges Verzeichnis:
  mkdir -p /var/log/Programm
end script

In einer Upstart-Job-Description steht hinter den Schlüsselworten start on das Ereignis, bei dem das hinter exec eingetragene Programm startet. Die Prozesse laufen allesamt im Vordergrund und nicht wie bei SysV-Init im Hintergrund. Das macht es für Upstart einfacher, zu prüfen, ob ein Prozess noch läuft. Bevor Upstart das Programm anwirft, führt es zunächst das zwischen pre-start script und end script hinterlegte Shellskript aus.

Das Drucksystem Cups fährt beispielsweise erst nach dem Ereignis “Dateisystem eingebunden” hoch, da es erst dann möglich ist, Dateien in die Spool-Verzeichnisse abzulegen. Voneinander unabhängige Ereignisse bearbeitet Upstart asynchron: So kümmert es etwa einen Fernsehempfänger in der Regel nicht, ob das Netzwerk bereits läuft. Die zugehörigen Jobs führt Upstart folglich parallel aus und beschäftigt so alle Rechenkerne moderner Prozessoren. Beim alten SysV-Init hätte die TV-Karte noch auf das Netzwerk warten müssen.

Das Beispiel aus Listing 1 zeigt aber auch einen Pferdefuß von Upstart: Wer nicht aufpasst, produziert eine Kette aus Abhängigkeiten, sodass die Dienste doch wieder nacheinander starten. Beispielsweise startet der Networkmanager erst, wenn D-Bus läuft, für das wiederum vorab Syslog seine Arbeit aufnehmen muss. Dem Autor eines Jobs beziehungsweise dem Distributor obliegt folglich die Aufgabe, ein Auge auf die Abhängigkeiten werfen und diese wohlüberlegt zu setzen.

Altlasten

Um nicht die über Jahrzehnte gewachsenen SysV-Init-Skripte über Nacht nutzlos zu machen, wertet Upstart sie weiterhin aus und startet entsprechend die Programme – allerdings wieder strikt nacheinander. Dank dieser weitreichenden Abwärtskompatibilität haben Distributionen die Möglichkeit, langsam und gefahrlos auf Upstart umzusteigen.

Das bestes Beispiel hierfür liefert Ubuntu: Upstart kam erstmals 2006 mit Version 6.10 “Edgy Eft” zum Einsatz, damals noch schlicht als 1:1-Ersatz für SysV-Init. Es dauerte im Anschluss noch drei Jahre, bis der Umstieg mit Ubuntu 9.10 abgeschlossen war und Upstart die Vorteile seines Konzepts erstmals unter Beweis stellen durfte. Doch selbst heute warten unter Ubuntu 10.10 im Verzeichnis /etc/init.d immer noch viele SysV-Init-Skripte auf die Migration. Nach Canonicals Plänen übernimmt Upstart zukünftig noch weitere Aufgaben und löst im Idealfall andere ereignisbasierte Dienste wie Cron, Anacron und Ard ab.

Upstart erlangte in den letzten Jahren so viel Beliebtheit, dass bereits andere namhafte Distributionen den Umstieg wagten. So kommt es beispielsweise in Fedora seit Version 9, in Googles Chromium OS und einigen Netbook-Betriebssystemen zum Einsatz. OpenSuse 11.3 ist noch nicht ganz soweit; dort tauschen die Entwickler das alte Init-System per Hand gegen Upstart aus, und selbst dann darf es nur stupide die alten SysV-Init-Skripte abarbeiten.

Noch ein Neuer

Obwohl sich Upstart gerade erst in den Distributionen etabliert, steht schon wieder ein Wechsel durch den vermutlich ärgsten Konkurrenten Systemd [3] ins Haus. Entwickelt hat das System Lennart Poettering, der unter anderem auch für das PulseAudio-System verantwortlich zeichnet. Als er Systemd im Frühjahr 2010 erstmals der Öffentlichkeit präsentierte, brach er mit seinem Prototypen und dem dahinter stehenden Konzept eine Welle los: Sein Konzept versprach unglaublich kurze Startzeiten und mehr freien Hauptspeicher.

Fedora bekundete bereits kurze Zeit später Interesse am Umstieg auf Systemd, der nach derzeitigem Planungsstand mit Fedora 15 erfolgen soll. Das frisch erschienene Fedora 14 hat zwar Systemd in Paketform als Option an Bord, bleibt aber vorerst noch beim bewährten Upstart als Default. Auch die OpenSuse-Maintainer planen für die nächste Version eine Integration des Newcomers Systemd, und in Debian findet sich seit Mitte November 2010 ebenfalls Systemd-Support – wenn auch noch als experimentell gekennzeichnet.

Systemd startet die Systemdienste erst dann, wenn man sie wirklich benötigt. So fährt der Daemon das Drucksystem Cups erst hoch, sobald Sie den Drucker aktivieren. Analog lauscht er auf den Netzwerkverkehr und startet den SSH-Dienst, wenn eine entsprechende Anfrage eingeht. Die Vorgehensweise hat sich Poettering übrigens vom altehrwürdigen inetd und von launchd aus Mac OS X abgeschaut.

Rabiater Trickser

Systemd arbeitet aber noch mit weiteren Tricks. Im Gegensatz zu Upstart ignoriert es die Abhängigkeiten der benötigten Dienste und startet sie einfach parallel. Möchte dabei ein Dienst auf Funktionen eines noch nicht gestarteten Kollegen zugreifen, landen diese Anfragen in einer Warteschlange. Systemd startet dann den benötigten Dienst und leitet die Daten in der Warteschlange an ihn weiter. Dank dieser Vorgehensweise können beispielsweise Programme ihre Fehlermeldungen abschicken, noch bevor der dafür zuständige Datensammler Syslog seine Arbeit aufgenommen hat.

Ein weiterer Dorn im Auge waren Lennart Poettering die vielen Init-Skripte: Für jedes Skript startet Init einen neuen Prozess. Zusätzlich erfordert es viel Zeit, sie zu analysieren und zu interpretieren. Aus diesem Grund sollen sie langfristig verschwinden. Ein Teil der Funktionen wandert direkt in Systemd, einen weiteren Part implementieren Poettering und seine Mitstreiter in C, und den Rest sollen die ausgeführten Dienste selbst übernehmen.

Die Liste der dazu von Lennart Poettering aufgestellten Forderungen fällt zwar lang aus, gut programmierte Dienste sollten die entsprechenden Konditionen jedoch ohnehin bereits jetzt erfüllen. Für bekannte Dienste haben die Systemd-Entwickler zudem passende Patches geschrieben und zur Integration an die Autoren der jeweiligen Daemons weitergereicht. Um die Abwärtskompatibilität sicher zu stellen, führt Systemd im Falle eines Falles weiterhin die alten SysV-Init-Skripte aus.

Kontrolleur

Um Dienste überwachen und nach einem Absturz automatisch neu starten zu können, greift Systemd auf die Hilfe des Linux-Kernels zurück: Er erlaubt es seit kurzem, Prozesse in Gruppen zusammen zu fassen. Diese Control Groups (kurz Cgroups) waren ursprünglich dazu gedacht, die Rechte und Ressourcen von laufenden Programmen und Prozessen einzuschränken.

Systemd packt jeden von ihm gestarteten Dienst in eine eigene Cgroup. Sollte in dieser Gruppe kein Prozess mehr laufen, ließe sich daraus folgern, dass der Dienst folglich abgestürzt oder beendet wäre. Auf diese Weise erfasst Systemd ganz ohne Verrenkungen Dienste, selbst wenn diese weitere Prozesse starten und sich direkt wieder beenden. Die Control Groups kommen allerdings erst ab Kernel 2.6.24 zum Einsatz; Systemd setzt sogar mindestens Version 2.6.30 voraus. Die Technik verhindert erst einmal das Portieren des Upstart-Konkurrent auf andere Betriebssysteme.

Baustelle

Jeder von Systemd zu überwachende Dienst erhält eine eigene Konfigurationsdatei, die im Fall von Fedora 14 etwas ungewöhnlich im Unterverzeichnis /lib/systemd/system liegt. Der Aufbau folgt den bekannten .desktop-Dateien, die mehrere Abschnitte aufweisen.

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
[Unit]
Description=Display Manager
After=syslog.target livesys-late.service rc-local.service
# On Fedora gdm/X11 is on tty1. We explicitly cancel the getty here to
# avoid any races around that.
Conflicts=getty@tty1.service plymouth-quit.service
[Service]
ExecStart=/etc/X11/prefdm -nodaemon
Restart=restart-always
RestartSec=0
[Install]
Alias=display-manager.service

Ein Beispiel für eine solche Konfigurationsdatei zeigt Listing 2, in der es um den Display-Manager geht. Hinter After= folgen alle von diesem benötigten Dienste, Conflicts= beschreibt analog alle Dienste, mit denen sich der Display-Manager ins Gehege kommt und die somit nicht laufen dürfen. ExecStart= nennt schließlich das eigentliche, auszuführende Programm.

Mit Restart=restart-always erhält Systemd die Anweisung, den Display-Manager nach einem Absturz immer wieder neu zu starten – und zwar umgehend (RestartSec=0). Abschließend definiert eine Anweisung, unter welchem Namen sich der Dienst noch meldet (Alias). Im Vergleich zwischen Listing 1 und Listing 2 fällt schnell auf, dass die Konfigurationsdateien unter Systemd zwar kleiner, aber mitunter etwas kryptischer ausfallen. Eine Liste mit allen Diensten und ihrem aktuellen Status liefert das Kommando systemctl (siehe Abbildung 2 und Abbildung 3).

systemctl liefert auf einem von Systemd betreuten Rechner eine Liste aller Dienste und deren jeweiligen Status. Dabei weist es sogar auf Abstürze hin.” width=”300″ height=”209″ /> Abbildung 2: Das Kommando systemctl liefert auf einem von Systemd betreuten Rechner eine Liste aller Dienste und deren jeweiligen Status. Dabei weist es sogar auf Abstürze hin.

Abbildung 3: Das Systemd-Paket enthält zusätzlich eine – wenn auch rudimentäre – grafische Benutzeroberfläche, über die Sie bei Bedarf einzelne Dienste starten und stoppen.

Systemd befindet sich derzeit noch mitten in der Entwicklung. Ähnlich wie Upstart soll auch Systemd künftig zusätzliche Aufgaben übernehmen und Dienste wie Cron ablösen. Ursprünglich war geplant, bereits in Fedora 14 Upstart gegen Systemd auszutauschen. Zahlreiche Fehler verhinderten dies jedoch, so dass es wie erwähnt nur als optionales Paket in den Repositories liegt.

Neben Lennart Poettering arbeiten derzeit viele weitere Entwickler daran, die letzten Fehler zu beseitigen und Systemd in Fedora 15 zu integrieren. Für andere Distributionen stehen zwar schon fertige Pakete bereit, die aber nicht immer oder nur unter ganz bestimmten Bedingungen funktionieren. Den Status des OpenSuse-Umstiegs verrät eine eigene Seite [4], das Pendant für Fedora 15 liegt unter [5].

Fazit

Upstart besitzt ein einfaches und klares Konzept, bleibt dabei jedoch vollständig abwärtskompatibel. Seine Fähigkeiten durfte es bislang jedoch erst ansatzweise in Ubuntu unter Beweis stellen. Die Gastspiele in Fedora und OpenSuse hingegen zeigten nicht das volle Potential. Konkurrent Systemd lockt Entwickler mit einem radikaleren Konzept, das noch schnellere Startzeiten verspricht, dafür aber unter der Haube komplexer ausfällt und spezielle Kernel-Funktionen verlangt.

Es sieht nicht so aus, als ob Canonical seine Eigenentwicklung Upstart so schnell wieder fallen ließe. Daher dürften zumindest im Jahr 2011 beide Systeme parallel existieren – und Programmentwicklern Mehrarbeit bescheren. Diese müssen ihren Diensten ein SysV-Init-Skript, einen Upstart-Job und eine Systemd-Konfigurationsdatei beilegen.

Als Benutzer merken Sie die Vorteile beider Systeme derzeit kaum: Ubuntu startet zwar mit jeder Version etwas flotter, bleibt vom Optimum aber noch weit entfernt. Ähnliches gilt für Systemd in Fedora 14, bei dem sich im Test subjektiv kaum einen Unterschied zum alten SysV-Init feststellen ließ. Beiden Lagern steht folglich noch einige Arbeit bevor.