Einschalten, loslegen: Mit Systemd versucht eine Gruppe Entwickler die Revolution im Boot-Prozess. Ob der Turbo aber wirklich zündet, steht noch in den Sternen.

Lange Zeit kontrollierte ein Werkzeug namens SysV-Init den Systemstart. Ihm kam die Aufgabe zu, alle für den Betrieb notwendigen Dienste und Anwendungen zu aktivieren. Dummerweise startete es stur einen Prozess nach dem anderen, was auf modernen, mit Funktionen vollgestopften Linux-Systemen entsprechend lange dauerte. Im Laufe der Jahre erschienen deshalb zahlreiche Alternativen, die es besser und vor allem schneller machen wollten.

Flotte Wollmilchsau

Eine besonders vielversprechende hört auf den Namen Systemd [1] und stammt vom Red-Hat-Mitarbeiters Lennart Poettering, aus dessen Feder unter anderem der NetworkManager stammt. Obwohl Systemd erst gerade im April seinen ersten Geburtstag feierte, schaffte die Software bereits den Sprung in Fedora 15. Andere Distributionen kündigten den Umstieg an; allerorten äußern sich Rezensenten fast ausschließlich begeistert.

Systemd sorgt nach der Definition des Erfinders nicht nur für einen flotten Start, sondern behält zusätzlich die gestarteten Dienste und Programme im Auge, kümmert sich um das Einhängen von Dateisystemen, ersetzt zukünftig den zeitgesteuerten Dienst Cron und dient außerdem als Session-Manager. Dabei verhält er sich abwärtskompatibel zu bestehenden SysV-Init-Skripten, die – im Laufe der Jahre gewachsen – für die Übergangszeit weiter ihren Dienst verrichten [2].

Um alle notwendigen Komponenten möglichst schnell zu starten, recycelt Systemd einige Ideen aus Mac OS X beziehungsweise dem dortigen Pendant Launchd und nutzt zusätzlich noch ein paar spezielle Funktionen des Linux-Kernels. Poetterings Programm erlaubt folglich keinen einfachen Port auf andere Unix-Systeme wie etwa FreeBSD.

Zunächst aktiviert Systemd nur die Dienste, die Sie tatsächlich benötigen. So müssen beispielsweise das Drucksystem Cups und sein Daemon nur dann die Arbeit aufnehmen, wenn ein Drucker angeschlossen ist oder eine Anwendung drucken möchte. Programme, die Systemd nicht anschiebt, blockieren nicht den Systemstart.

Die verbleibenden Dienste startet Systemd einfach gleichzeitig. Dummerweise hängen viele Dienste voneinander ab. Beispielsweise benötigt der Netzwerkkonfigurator Avahi den D-Bus, der wiederum Syslog voraussetzt. Im Extremfall starten doch wieder alle Beteiligten nacheinander. Systemd umgeht dieses Problem mit einem kleinen Trick. Um dessen Funktionsweise zu verstehen, gilt es allerdings, einen kleinen Blick unter die Haube zu werfen.

Steckverbinder

Linux-Programme kommunizieren mit Diensten über sogenannte Sockets. Diese entsprechen von der Funktion in etwa Fluggastbrücken an einem Flughafen: Ein Flugzeug dockt dort an und entlädt seinen Inhalt in das Terminal. Analog stellt jeder Dienst einen Socket bereit, der anderen Programmen die Möglichkeit bietet, sich anzudocken und Anfragen an den Dienst abzuladen.

Der Trick besteht nun darin, diese Sockets schon bereitzustellen, noch bevor der entsprechende Dienst vollständig gestartet ist. In der Metapher entspräche das ein paar Gangways, die bereits auf dem Rollfeld stehen, obwohl sich das Terminal dahinter noch im Rohbau befindet. Sollte jetzt ein Flugzeug eintrudeln, entlädt es seine Passagiere in die Gangway, wo die Reisenden dann noch kurz auf das Fertigstellen der Gebäude warten müssen. Das Flugzeug selbst hebt derweil aber schon wieder ab.

Genau das Gleiche macht Systemd beispielsweise mit dem syslog-Dienst, der alle ihm übergebenen Nachrichten in eine Log-Datei schreibt: Systemd erstellt für ihn direkt beim Systemstart prophylaktisch einen Socket. Möchte jetzt ein Programm eine Fehlermeldung loswerden, schiebt es diese Daten in den Socket. Sollte syslog noch nicht laufen, wandern die Meldungen in einen Zwischenpuffer. Solange dieser nicht vollläuft, müssen die Programme nicht auf den Start von syslog warten, sondern können einfach schon mit ihrer Arbeit weitermachen. Nachdem syslog gestartet ist, nimmt es sich der angesammelten Nachrichten im Puffer an und arbeitet sie ab.

Netterweise verwaltet der Linux-Kernel diese Warteschlangen. Systemd muss somit nur noch alle benötigten Sockets einrichten und kann dann alle zugehörigen Dienste parallel starten. Diese Arbeitsweise spart nicht nur Verwaltungsaufwand und somit Zeit, sie hat sogar noch ein paar angenehme Nebeneffekte: Sollte ein Dienst das Zeitliche segnen und sich beenden, existiert der Socket weiter. Die jetzt folgenden Anfragen der Programme gehen somit nicht verloren, sondern wandern in den Zwischenpuffer. Damit kann man auch einen Dienst im laufenden Betrieb neustarten oder austauschen – wie etwa bei einer Aktualisierung – ohne dass die Programme dies überhaupt bemerken. Es lassen sich sogar die Sockets öffnen und erst wenn irgendwann darüber Nachrichten eingehen, die dazu passenden Diensten starten (Start on Demand, auch On Demand Loading genannt). Systemd übernimmt damit gleichzeitig die Aufgaben von Programmen wie inetd.

Mittlerweile nutzen viele Dienste und insbesondere Programme mit einer grafischen Benutzeroberfläche anstelle der Sockets den D-Bus als Kommunikationsmittel. Glücklicherweise funktioniert die obige Methode auch mit D-Bus-Diensten (Stichwort Bus Activation): Systemd meldet einfach schon einmal ein paar Dienste namentlich beim D-Bus an und startet erst danach die zugehörigen Programme.

Big Brother

Stürzt ein lebenswichtiger Dienst ab, sollte Systemd ihn möglichst schnell neu starten. Da sich jedoch ein Dienst selbst zu klonen vermag und bei Bedarf weitere Programme startet, fiel es in der Vergangenheit schwer, dessen endgültiges Ableben festzustellen.

Systemd löst das Problem recht elegant mit Hilfe der relativ neuen Control Groups, kurz Cgroups des Linux-Kernels. Mit diesen fasst das Betriebssystem Programme oder genauer gesagt Prozesse zusammen. Systemd sperrt nun jeden von ihm gestarteten Dienst in eine solche Gruppe. Sollte der Dienst weitere Programme aktivieren oder Kopien von sich selbst erstellen (forken), wie es beispielsweise Webserver oder SSH-Daemons tun, landen die Kind-Prozesse in der gleichen Gruppe. Befindet sich kein aktiver Prozess mehr in einer Gruppe, gilt der Dienst als abgestürzt oder beendet. Systemd startet ihn dann neu.

Der Systemd kümmert sich aber nicht nur um Dienste, sondern hängt bei Bedarf Partitionen ein und prüft sie auf Fehler. Damit diese zeitaufwendigen Aufgaben wieder nebenbei und parallel zum Start aller Dienste passieren, greift Systemd hier auf die Hilfe von Autofs [3] zurück: Versucht ein Programm in ein noch nicht verfügbares Device zu speichern, puffert der Kernel die Anfrage. Sobald das Dateisystem schließlich bereit steht, gibt er die Daten weiter.

Dieses Prinzip ermöglicht es, zum Beispiel die Home-Partition im Netzwerk via Samba freizugeben, obwohl Fsck sie gerade noch auf Fehler prüft. Ergänzend überwacht Systemd einzelne Verzeichnisse und sobald ein Programm darauf zugreift, hängt er automatisch das passende Dateisystem ein.

Muschelersatz

Die meisten Distributionen starten bislang die einzelnen Dienste via Shell-Skript. Das Starten von externen Programmen und Subshells schluckt allerdings extrem viel Rechenzeit. Darüber hinaus nutzen viele Skripte rekursive Konstrukte sowie redundante Befehle, sind fehleranfällig und irgendwann schwierig zu warten. Daher sind Poettering sämtliche Skripte ein Dorn im Auge, weshalb er sie bei der Arbeit an Systemd konsequent vermieden hat.

Die Maintainer sollen die Funktionen der Skripte durch richtige, vorzugsweise in C geschriebene und somit schnell ablaufende Programme ersetzen oder in die Daemons selbst integrieren. Einige besonders wichtige und gebräuchliche Funktionen übernimmt Systemd selbst.

Derzeit vermag er unter anderem den Hostnamen zu setzen (also den Namen des Computers), sich wie erwähnt um das Mounten der Dateisysteme kümmern und die Sprache einstellen (System Locale). Die diesbezüglichen Einstellungen liest Systemd aus den bekannten Konfigurationsdateien – zumindest fast.

In einigen Fällen nutzen die Distributionen nämlich unterschiedliche Dateien. Der Name des Systems liegt beispielsweise unter Fedora in /etc/sysconfig/network, OpenSuse benutzt /etc/HOSTNAME und Debian wiederum /etc/hostname. In solchen Fällen haben sich die Systemd-Macher für eine Datei entschieden. Den Hostnamen erwartet Systemd beispielsweise in /etc/hostname. Auf diese Weise versuchen die Systemd-Entwickler die Distributionen durch die Hintertür weiter zu standardisieren.

Die Tabelle “Wichtige Verzeichnisse und Konfigurationsdateien” zeigt einen kleinen Überblick über die wichtigsten Konfigurationsdateien und Verzeichnisse, die übrigens in Absprache mit den Distributoren entstanden sein sollen. Weitere Informationen hierzu liefert Lennart Poettering in seinem Blog [4].

Einheitsbrei

Systemd bezeichnet alle von ihm zu verwaltenden Aufgaben als “Units” (Einheiten). Eine Unit umfasst beispielsweise den Druckdienst Cups, eine andere das Einhängen des Heimatverzeichnisses. Beide Units erfordern offensichtlich unterschiedliche Aktionen. Daher besitzt jede Unit einen ganz bestimmten Typ.

Bei Cups handelt es sich um einen Dienst und somit um den Typ service, das Einhängen wäre hingegen vom Typ mount. Damit Systemd überhaupt von der Unit erfährt, braucht es eine passende Konfigurationsdatei. Sie trägt den gleichen Namen wie die Unit, der sich wiederum aus einem frei wählbaren Namen und dem Typ zusammensetzt.

So bietet es sich zum Beispiel an, die Konfigurationsdatei für den Druckdienst cups.service zu nennen. Neben service und mount kennt Systemd noch weitere Kategorien, die Sie in der Tabelle “Unit-Typen” finden.

Heimwerker

Um einen eigenen Dienst beim Start zu aktivieren, gilt es eine passende Konfigurationsdatei zu erstellen. Listing 1 zeigt die Datei laermmessung.service als kleines Beispiel für die Software einer Lärmmessstation.

[Unit]
Description=Dieser Dienst zeichnet den Fluglärm auf.
After=syslog.target
[Service]
ExecStart=/usr/bin/laermmessung
Restart=on-abort
[Install]
WantedBy=multi-user.target

Die Konfigurationsdateien benutzen einen ähnlichen Aufbau wie die weit verbreiteten .desktop-Dateien. Der Abschnitt [Unit] enthält ein paar allgemeine Informationen über den Dienst. Dazu zählt eine kurze, für Menschen gedachte Beschreibung (Description) des Dienstes.

Die Software meldet Probleme über den Dienst syslog und schreibt die aufgezeichneten Daten in Dateien auf die Festplatte. Unter Systemd dürfen alle Dienste mit einem vorhandenen Dateisystem rechnen; folglich brauchen Sie dies nicht extra sicherstellen. Bleibt die Abhängigkeit zum Dienst syslog. Darum kümmert sich in Zeile 3 der Parameter After=. Hier tragen Sie einfach die Unit ein, von der das Programm abhängt.

Bei mehreren Abhängigkeiten listen Sie die Unit-Namen einfach durch Leerzeichen voneinander getrennt auf. Unter Umständen fällt diese Liste jedoch recht lang aus. Damit Sie sich nicht die Finger wund tippen, gibt es die Target-Units. Damit gruppieren Sie mehrere Units unter einem einheitlichen Namen.

Systemd bringt bereits ein paar spezielle Target-Units von Haus aus mit [5]. Dazu gehört unter anderem auch syslog.target, das Listing 1 verwendet. Diese Unit sorgt schlichtweg für den Start einer Syslog-Implementation.

Da Systemd möglichst viele Dienste parallel aktiviert, dient die Angabe hier nur dazu, eine (Start-)Reihenfolge vorzuschlagen und nicht zu erzwingen. Ergänzend zu After kennt Systemd noch die Anweisungen aus Tabelle “Bedingungen für einen Dienst”.

Der nächste Abschnitt [Service] gibt ein paar Informationen über den Dienst selbst preis. Er existiert folglich nur in Konfigurationsdateien vom Typ .service. Mit ExecStart= geben Sie den Namen der Programmdatei an, im Beispiel /usr/bin/laermmessung. Systemd ruft sie auf, wenn er den Dienst startet.

Wie von Systemd generell gefordert, läuft die Software im Vordergrund. Will der Dienst-Daemon dennoch unbedingt im Hintergrund laufen, beziehungsweise einen Fork erstellen, teilen Sie dies Systemd über den Parameter Type=forking mit (Listing 2). Und auch für den Fall, dass der Dienst den D-Bus nutzt, gibt es eine entsprechende Variante (Listing 3).

[Service]
ExecStart=/usr/bin/laermmessung -d
Type=forking
Restart=on-abort

[Service]
Type=dbus
BusName=de.dfld.laermmessung
ExecStart=/usr/bin/laermmessung

Der Parameter BusName= nennt den D-Bus-Namen der Software. Über Restart=on-abort sorgen Sie dafür, dass Systemd den Dienst neu startet, sobald sich dieser aus irgendeinem Grund beendet.

Der letzte Abschnitt [Install] aus Listing 1 teilt dem Systemd mit, wann und unter welchen Bedingungen Sie den Dienst starten wollen. Im Beispiel beginnt die Software mit der Arbeit (WantedBy), wenn Systemd die Unit multi-user.target aktiviert. Sie kapselt alle Dienste, die für den Betrieb eines Mehrbenutzersystems notwendig sind.

Feuer frei

Die fertige Konfigurationsdatei wandert nun unter dem Namen laermmessung.service in das Verzeichnis /etc/systemd/system/. Dort hinein gehören alle eigenen Konfigurationsdateien, die vom System mitgebrachte lagern hingegen unter /lib/systemd/system/. Mit dem Befehl

$ sudo systemctl daemon-reload

liest Systemd die geänderte Konfiguration. Den neuen Dienst startet schließlich der Aufruf

$ sudo systemctl start laermmessung.service

Dass der Dienst läuft, verrät ebenfalls das Kommando systemctl, diesmal allerdings mit dem Befehl status statt start (Abbildung 1). Eine Übersicht über die Befehle für die Software liefert die Tabelle “Systemctl-Kommandos”.

systemctl status cups.service erfahren Sie alle Einzelheiten über den Druckdienst.” width=”300″ height=”77″ /> Abbildung 1: Mit dem Kommando systemctl status cups.service erfahren Sie alle Einzelheiten über den Druckdienst.

Wer hat’s gesehen?

Das Werkzeug Systemctl hilft als kleiner Tausendsassa in vielen weiteren Lebenslagen. Ein einfaches systemctl liefert zunächst eine Liste aller laufenden Dienste (Abbildung 2). Ein besonderes Augenmerk verdient die Spalte active: Sie zeigt an, ob ein Dienst derzeit läuft (active), nicht arbeitet (inactive) oder ob bei seiner Inbetriebnahme ein Problem auftrat (maintenance). Über systemctl status Unit erfahren Sie weitere Informationen zum Zustand.

Abbildung 2: Systemctl zeigt eine Liste mit allen vorhandenen Diensten, ihrem Status und der Beschreibung an.

Per isolate weisen Sie Systemd an, die Units eines ganz bestimmten Targets herzustellen:

$ sudo systemctl isolate multi-user.target

Dieses Beispiel aktiviert alle Units, die für einen Mehrbenutzermodus ohne grafische Oberfläche notwendig sind. Für alle, die noch in Runleveln aus SysV-Init-Zeiten denken, liefert Systemd passende Targets mit, die das alte Verhalten simulieren. Beispielsweise wechselt:

$ sudo systemctl isolate runlevel5.target

in einen Systemzustand mit grafischer Benutzeroberfläche. Beim Booten aktiviert Systemd übrigens standardmäßig das Target default.target. Dahinter verbirgt sich ein symbolischer Link, der auf eine andere Konfigurationsdatei zeigt. Unter Fedora 15 ist dies noch das runlevel5.target, zukünftig schwenken die Entwickler wohl auf das Systemd-Pendant graphical.target um.

Mit Systemd hält auch ein neuer Befehl Einzug, um das komplette System kontrolliert herunterzufahren und auszuschalten:

$ sudo systemctl --force poweroff

Die alten Befehle wie shutdown und reboot funktionieren allerdings weiterhin, Systemd übersetzt sie passend. Wer anstelle von Systemctl eine grafische Oberfläche bevorzugt, greift zu Systemadm aus dem Paket systemd-gtk (Abbildung 3).

Abbildung 3: Mit Systemadm aktivieren und deaktivieren Sie alle vorhandenen Units bequem per Mausklick.

Systemd protokolliert penibel seinen Systemstart. Per systemd-analyze blame erfahren Sie, wie lang welcher Dienst für den Start benötigt hat (Abbildung 4), einen passenden netten Graphen erzeugt:

$ sudo systemd-analyze plot > ergebnis.svg

Abbildung 4: Systemd merkt sich, welche Dienste wie lange beim Start getrödelt haben.

Als Ergebnis erhalten Sie dann ein SVG-Bild in der Datei ergebnis.svg, das Sie beispielsweise in Inkscape oder einem geeigneten Browser begutachten (Abbildung 5).

Abbildung 5: Bei Bedarf erzeugen Sie ein Diagramm, das den Systemstart und die dabei benötigten Zeiten zeigt.

ExecStartPre=/bin/rm -f /var/log/messungen

Ausblick

Obwohl die Konfigurationsdatei aus Listing 1 auf den ersten Blick rank und schlank wirkt, ist Systemd komplizierter als der Konkurrent Upstart. Wer das Werkzeug verstehen will, dem bleibt nichts anderes übrig, als sich durch zahlreiche Texte kämpfen, die Lennart Poettering häppchenweise in seinem Blog [6] sowie in derzeit satten 45 Manpages veröffentlicht hat [7].

Systemd fordert von den Entwicklern der Dienste ein Anpassen der Software und somit zusätzlichen Programmieraufwand – obwohl sich dieser in Grenzen hält. Administratoren müssen sich zudem von den geliebten Shell-Skripten verabschieden. Das alles verspricht unter dem Strich einen schnellen Systemstart. Im kleinen Vergleichstest startete jedoch unter exakt gleichen Bedingungen die letzte Vorabversion von Fedora 15 etwa fünf Sekunden langsamer als Ubuntu 11.04 mit dem Konkurrenten Upstart.

Allerdings lässt das Ergebnis noch keine Rückschlüsse auf die tatsächlichen Möglichkeiten von Systemd zu: Upstart hat schon ein paar Jahre auf dem Buckel und ist entsprechend optimiert, Systemd feierte gerade einmal seinen ersten Geburtstag und unterliegt immer noch ständigen Änderungen.

Dennoch erfreut es sich bei den Distributoren zunehmender Beliebtheit. Fedora 14 lag Systemd schon als optionales Paket bei, ab Fedora 15 kommt es standardmäßig zum Einsatz. OpenSuse, Debian und andere Distributionen liebäugeln ebenfalls mit Systemd.

Wer es ausprobieren möchte, findet auf der Systemd-Homepage Links auf Pakete für zahlreiche Distributionen – darunter sogar welche für Ubuntu. Dessen Distributor Canonical setzt jedoch aller Voraussicht nach weiter auf den Eigenbau Upstart.

Aufgrund der breiten Unterstützung dürfte sich Systemd mittelfristig als Standard durchsetzen. Ob der Verzicht auf flexible Skripte und das Festnageln auf Linux-exklusive Funktionen wirklich einen Schritt nach vorne darstellt, muss sich erst noch erweisen.