» Systemstart mit...
© Arinas74, sxc.hu
Mit Volldampf zu neuen Ufern
Systemstart mit Systemd
Tim Schürmann 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.
Systemstart Durchstarten Die Neuerungen der Version 198
Die frisch veröffentlichte Version bietet neben neuen Werkzeugen unter anderem auch die Möglichkeit, die Unit-Definitionen mit zusätzlichen Konfigurationsdateien zu überschreiben. Neuerungen in Systemd
Auf der Mailingliste hat Systemd-Entwickler Lennart Poettering Version 202 der Software angekündigt.