© Shariff Che'Lah, 123RF.com

Sys-V-Init startete die Prozesse von Linux mehr als ein Jahrzehnt lang als Einzelkämpfer. Doch heute lauert eine technisch versierte Generation von Initsystemen in den Startblöcken.

Viele Jahre lang startete der Linux-Kernel als erste Amtshandlung einen Prozess und stattete diesen mit der Prozess-ID 1 aus: Init. Der Startprozess warf zunächst einen Blick in die Datei »/etc/inittab« und schlurfte anschließend gemütlich durch die Runlevel des Sys-V-Init-Systems (Abbildung 1).

Abbildung 1: Init durchläuft im Sys-V-System verschiedene Runlevel, welche die Datei »inittab« festlegt, und führt jeweils einige Initskripte aus.

In jedem Runlevel startete Init, unterstützt von so genannten Initskripten, verschiedene Dienste und hörte erst damit auf, wenn es den anfangs anvisierten Runlevel erreicht hatte. Handelte es sich zum Beispiel um Debian und war das Ziel der Runlevel 1, saß der Benutzer am Ende vor einem Rechner ohne Netzwerk und grafischer Oberfläche, war aber in der Lage, lokale Anwendungen zu nutzen. Beim Herunterfahren des Rechners wurden die Dienste dann wieder gestoppt.

Von Simpleinit zu Sys-V-Init

Wie der Name schon andeutet, kam Sys-V-Init nicht aus dem luftleeren Raum, sondern orientierte sich am Runlevel-System von System-V, AT&Ts kommerziellem Unix-System von 1983. Miquel van Smoorenburg hatte Sys-V-Init 1992 für Minix portiert, der Däne Ørbæk entwickelte daraus eine Version für Linux, die im April 1992 in Version 1.0 von »admutil« debütierte [1].

Dabei war Sys-V-Init weder das erste noch das einzige Initsystem für Linux. Das verwendete zunächst Simpleinit [2], ein Init-basiertes System, das Ørbæk unter Mithilfe von Werner Almesberger entwickelt hatte. Es war etwas einfacher gestrickt als Sys-V-Init, weil es unter anderem keine Runlevel mitbrachte, und steckte im »poeigl« -Archiv.

Ende 1992, nach der Veröffentlichung von »admutil-1.4« , entspann sich im Usenet jedoch eine Diskussion [3] über das passende Initsystem. Ausgangspunkt waren Ørbæks Pläne, die Logout Records von dem Tool Getty schreiben zu lassen. Ein User wies darauf hin, dass man diesen Job in bester Unix-Manier wohl eher Init überlassen solle, und berichtete nebenbei von seinen guten Erfahrungen mit Sys-V-Init. Ørbæk willigte ein, Sys-V-Init zum Standard der nächsten Version seiner Werkzeugsammlung zu machen, Simpleinit sei mittlerweile ohnehin “zu groß” geworden.

Doch die Pläne änderten sich, weil der Sys-V-Init-Autor Miquel van Smoorenburg im Dezember 1992 die weitere Entwicklung des Tools unter Linux übernahm und Version 2.0 veröffentlichte [4]. Er hatte sich inzwischen einen 386er besorgt, Linux installiert und baute nun den Code von Sys-V-Init komplett um. Die ursprüngliche Minix-Unterstützung ging dabei verloren, dafür landete Sys-V-Init bald danach im Kernel und avancierte auch zum Bootsystem für Softlanding Linux, der ersten Linux-Distribution überhaupt. Smoorenburg betreute Sys-V-Init zwölf Jahre lang, bis er das Projekt 2004 einstellte.

Rückzugsgefechte

Smoorenburg ging, zurück blieb ein verwaistes Projekt mit Versionsnummer 2.86, das dennoch weiter zum Einsatz kam. Der Debian-Entwickler Petter Reinholdtsen kümmerte sich inoffiziell um Bugreports für Sys-V-Init, brachte Patches ein und veröffentlichte gepatchte Varianten der Version, die auch Ubuntu verwendete.

Fünf Jahre lang hielt der für Reinholdtsen frustrierende Zustand an, bevor er im Juli 2009 das Projekt zusammen mit einigen Helfern übernahm [5], sich kurzerhand zum neuen Upstream erklärte und die neue Version 2.87dsf von Sys-V-Init veröffentlichte. Mit dem Wechsel des Betreuers ging auch ein Wechsel des Repository einher: Seitdem hostet Savannah [6] den Code. Reinholdtsen sah durchaus die Ironie bei dieser Übernahme, denn einige Distributionen dachten zu diesem Zeitpunkt bereits über einen Wechsel zu Ubuntus neuem Initsystem nach.

Upstart

In erster Linie ein Kind des Ubuntu-Entwicklers Scott James Remnant, sollte Upstart die Nachteile des in die Jahre gekommenen Sys-V-Init ausbügeln. Diese lagen unter anderem darin, dass Sys-V-Init mit einem ganz anderen Modell vom Computer im Hinterkopf entwickelt wurde. Es ging von Desktoprechnern aus, die einmal hochgefahren wurden und dann ohne große Änderungen an der Hardware eine ganze Weile liefen. 2006, als Remnant mit der Entwicklung von Upstart begann, waren USB-Sticks, mobile Festplatten und externe USB-Geräte bereits gang und gäbe.

Upstart ermöglicht es, Dienste flexibel und Ereignis-basiert zu starten und zu stoppen, und beschleunigt so auch den Startvorgang. Denn Sys-V-Init verschleppt den Bootprozess gelegentlich, weil abhängige Dienste nicht verfügbar sind und es die weiteren Skripte erst nach einem Timeout ausführt.

Upstart legt keine Bootziele fest, um Services zu starten, vielmehr reagieren diese auf bestimmte Events. Indem er einen Job definiert, sorgt der Admin etwa dafür, dass Apache startet, sobald ein Netzwerk verfügbar ist. Auf Wunsch kann ein Ereignis auch mehrere Jobs auslösen, die parallel laufen. Die Syntax ist im Vergleich zu Sys-V-Init recht einfach.

Fedora, das Upstart Ende 2008 in seine Version 10 integrierte [7], wollte vor allem die zahlreichen, mit Sys-V-Init verbundenen Bash-Skripte loswerden. Debian sah in Upstart die Antwort auf einen zunehmend Event-basierten Kernel und wollte damit die Probleme lösen, die ein sequenzieller Bootprozess gelegentlich mit sich brachte. Petter Reinholdtsen schlug den Wechsel von Debian zu Upstart vor [8], doch erst Ende 2012 landete ein Paket in Debian Unstable.

In Ubuntu werkelt Upstart bereits seit Oktober 2006, entfaltete aber anfangs kaum Wirkung, weil die Entwickler zunächst das Verhalten von Sys-V-Init nachbauten. Erst für die 9er Versionen ersetzte das Ubuntu-Projekt zahlreiche Initskripte durch Upstart-Jobs (Abbildung 2).

Abbildung 2: Auszug aus einer mit Bootchart erzeugten Grafik unter Ubuntu 9.04.

Upstart reloaded

2011 erlitt Upstart vorübergehend einen Rückschlag, als der Hauptentwickler Scott James Remnant das Projekt verließ. Er wechselte zu Google, um an Chrome OS zu arbeiten, das ebenfalls auf Upstart setzt. Im Laufe des Jahres gingen seine Beiträge auf der Mailingliste deutlich zurück, seinen Platz übernahm Canoncials James Hunt, ein ehemaliger IBM-Angestellter. Er kümmert sich bis heute um Upstart, gibt neue Versionen heraus und beantwortete dem Linux-Magazin auch Fragen zum Projekt.

Laut Hunt wirken aktuell etwa 20 Leute an Upstart mit, darunter hauptsächlich Canonical-Angestellte. Die Software sei nicht nur Teil aller Ubuntu-Installationen weltweit, sondern laufe auch unter Chrome OS und auf älteren Fedora-Versionen. Kommuniziert werde über die Mailingliste und einen IRC-Channel, den Code und die Bugreports verwalte das Projekt in Ubuntus Launchpad-Plattform.

Zu den Änderungen, die Hunt bisher anschob, gehört das Einrichten eines Daily Repository, das täglich Upstart-Versionen baut. Änderungen am Code landen automatisch auf der Mailingliste. Zusätzlich zu Scan-Build und Smatch kommt Coverty Scan für die statische Code-Analyse zum Einsatz. Auch automatische Tests wolle man künftig verstärkt nutzen.

Zu den größten Konflikten der jüngeren Projektgeschichte zählt Hunt die Debatte um Canonicals Contribution Agreement, als deren Folge das Contributor License Agreement (CLA) entstand. Dies erlaubt es Canonical zwar noch immer, den Code für Upstart und andere Projekte auch proprietär zu lizenzieren, doch die Entwickler behalten das Recht, ihn frei zu lizenzieren und zu verteilen.

Systemd

Noch in die Amtszeit von Remnant fiel eine weitere Überraschung: Systemd. Lennart Poettering, der Kopf hinter Avahi und Pulseaudio und seines Zeichens Red-Hat-Entwickler, kündigte das alternative Initsystem 2010 in seinem Blog an [9]. Wie er im E-Mail-Interview schreibt, arbeitete er bereits vor dem Erscheinen von Upstart privat an einem Initsystem namens Babykit, legte dies aber nach dem Upstart-Announcement wieder zu den Akten.

Auf der Linux Plumbers Conference 2009 habe er dann zusammen mit seinem Kollegen Kay Sievers festgestellt, dass Upstart einen falschen Ansatz verfolgt, weil es vom Benutzer Vorleistungen erwarte, statt die minimale Anzahl benötigter Dienste selbst zu ermitteln. Also habe er die Pläne aus der Schublade geholt, sich Solaris’ SMF und Apples Launchd genau angesehen und im November 2009 begonnen Code für Systemd zu entwickeln.

Zukunftspläne

Technisch will Systemd Dienste massiv parallelisieren, indem es sie auf unterschiedlichen Wegen aktiviert: über Sockets, Busse, Geräte, Pfade oder Timer. Traditionell warten Daemons unter Linux zudem darauf, dass die Sockets anderer Daemons auf Empfang gehen, bevor sie Anfragen senden. Das will Systemd ändern, indem es alle Sockets aktiviert, bevor es die zugehörigen Daemons startet. Die Anfragen landen im Socket-Puffer, wo sie der Kernel verwaltet.

Ist der Daemon schließlich online, arbeitet er die Warteschlange ab. Erwartet ein Client auf seine synchrone Anfrage eine Antwort, muss er sich zwar gedulden, bis der Daemon läuft, blockiert aber keine anderen Dienste. Da alle Sockets aktiv sind, spielen auch Abhängigkeiten der Daemons voneinander keine Rolle.

Doch die Pläne gehen weiter. So wollen die Systemd-Entwickler, zu denen hauptsächlich Kay Sievers, Zbigniew Jedrzejewski-Szmek und Lennart Poettering gehören, dass Systemd auch das Festplattenmanagement beim Systemstart übernimmt, also Aufgaben wie das Mounten, Gesundheitschecks, die Platzverwaltung oder das Swappen.

Zudem will die Mannschaft Prozesse über das Cgroups-Feature im Kernel verfolgen, um die Dienste so im Auge zu behalten und bei Abstürzen neu zu starten oder zumindest Crash-Informationen zu sammeln. Systemd soll auch Logdateien für Daemons anlegen, an Luks, Selinux und PAM andocken, Locales verwalten, Konsolen und Keyboards einrichten und vieles mehr. Sein Projekt habe, schreibt Poettering, “den Fokus von Systemd etwas ausgedehnt”. Eine komplette Übersicht der geplanten Aufgaben von Systemd gibt ([10], Abbildung 3).

Abbildung 3: In einer sehr langen Tabelle (hier nur ein kurzer Auszug) listet Lennart Poettering in seinem Blog zahlreiche Funktionen auf, die Systemd künftig übernehmen soll.

Bei vielen Entwicklern weckt die Menge an Funktionen in Systemd Besorgnis. Poettering verteidigt die Pläne: Er sieht die Chance, die verschiedenen Eigenlösungen und Skripte der Distributionen abzuschaffen, indem Systemd die neuen Features von Linux intelligent einsetze und das Startsystem vereinheitliche.

Viele Linux-Nutzer haben jedoch den alten Unix-Spruch “Do one thing and do it well” verinnerlicht. Seine Gegner werfen ihm vor, er mache kleineren Distributionen, die auf Systemd verzichten wollen, das Leben schwer, indem er zahlreiche Dienste mit seinem Initsystem verknüpfe [11]. Einige Gentoo-Entwickler gründeten mit Eudev [12] einen Fork von Udev, nachdem Systemd den Udev-Code in die eigene Codebasis integrierte.

Solche Vorwürfe hält der Entwickler für überzogen und will sie in seinem Blog entkräften. Doch seine offensive Art polarisiert, auch die Unbekümmertheit, mit der er vermeintlich alte Zöpfe abschneidet, kommt nicht überall gut an.

Im Projekt selbst gehe es hingegen harmonisch zu, schreibt Poettering. Commit-Berechtigung für Systemd haben demnach 17 Personen, im Repository stecken Patches von 400 Leuten, 600 Personen stehen auf der Mailingliste. Über diese kommunizieren alle, außerdem gebe es mehrmals im Jahr Hackfeste, und regelmäßig telefoniere er mit seinem Mitentwickler Kay Sievers. Den Code von Systemd verwaltet Git, Bugs werden in den Bugtrackern von Fedora und Freedesktop.org verfolgt. Aktuell komme Systemd unter Fedora, Open Suse, Arch-Linux, Mandriva, Mageia, Tizen und Mer, einem Fork von Meego, zum Einsatz.

Für Debian gibt es zwar Systemd-Pakete, doch es nutzt noch immer Sys-V-Init. Auch Linux Mint hat nicht gewechselt, vielleicht weil Ubuntu an Upstart festhält. Mark Shuttleworth begründete das in seinem Blog damit, dass Upstart sorgfältig designt, gut getestet sei und es zudem eine klare Aufgabe habe [13].

Ausblick

Die Entwickler von Upstart beziehungsweise Systemd, begründen ihre Neuentwicklungen vor allem mit technischen Argumenten. Während Upstart das zeitweise nur dürftig betreute und nicht mehr zeitgemäße Sys-V-Init ablöste, rechtfertigen die Systemd-Macher ihren Neubau damit, dass sie Upstarts Konzept vom Kopf auf die Füße stellen wollen.

Dass auch unternehmerische Gründe hinter den Entscheidungen stecken, würden die Entwickler wohl bestreiten. Dennoch: Für Upstart besitzt Canonical ein Contributor License Agreement, kann also die Software notfalls unter eine proprietäre Lizenz stellen, etwa auf Mobilgeräten. Zudem ist Upstart nach längerer Entwicklung ein gut angepasster Bestandteil von Ubuntu und Canonical bezahlt die meisten seiner Entwickler. Das Initprogramm dürfte man allein deshalb nicht ohne triftige Gründe über Bord werfen.

Die Entwickler von Systemd arbeiten hingegen für Red Hat. Das Unternehmen aus Raleigh hat sich nicht offiziell zu den Plänen geäußert, aber es ist sicher nicht unpraktisch, die Experten für das neue System auf der eigenen Lohnliste zu haben. Weil Canonical aus besagten Gründen vorerst nicht wechseln wird, besitzt Fedora zudem ein Alleinstellungsmerkmal, das sich aufgrund der Komplexität von Systemd nicht ohne Weiteres nachbauen lässt.

Ob dieser Technologiewettstreit, der auch Wayland und Mir sowie Unity und Gnome berührt, der Linux-Community eher nützt oder schadet, muss sich noch zeigen. Insbesondere die Anhänger und Entwickler kleinerer Distributionen dürften den Konflikt genau beobachten.

Während einige Systeme sich bereits für Systemd entschieden haben (etwa Arch Linux), bleiben andere einfach bei Sys-V-Init (Debian) oder nutzen gleich eine eigene Variante des Bootsystems wie Open RC (Gentoo). Dank der freien Lizenzen beider Bootsysteme ist zur Not auch ein späterer Wechsel möglich.