Software::Systemverwaltung
systemd - Alternative zu init vorgeschlagen
Der Red-Hat-Entwickler Lennart Poettering hat ein Projekt gestartet, um den Prozess mit der PID 1 - in normalen UNIX- und Linux-Systemen init genannt, zu ersetzen.
Lennart Poettering
systemadm zur Verwaltung von systemd
Poettering ist hauptsächlich als Autor von PulseAudio bekannt, für das er vielfach kritisiert wurde - vielleicht zu Unrecht, denn es waren Distributionen wie Fedora und Ubuntu, die PulseAudio in die Standardinstallation aufnahmen, ohne das korrekte Funktionieren sicherzustellen.
Poetterings neuestes Projekt ist systemd, ein Ersatz für das in die Jahre gekommene init-Programm oder Upstart. Er betreibt dieses Projekt, das er in einem langen Artikel beschreibt, in seiner Freizeit. An dem Projekt, das Linux-spezifisch, aber distributionsübergreifend ist, sind auch Kay Sievers (Novell) und mehrere andere Entwickler beteiligt.
Bevor systemd ins Leben gerufen wurde, untersuchte Poettering die zahlreichen Alternativen zu init, fand aber nichts, was die Anforderungen erfüllte. Auch das von Ubuntu entwickelte Upstart ist seiner Ansicht nach nicht ausreichend. Es hat zwar den Bootvorgang bereits massiv beschleunigt, stellt aber nur eine Obermenge von SysV-Init dar und ist nicht so effizient, wie es sein sollte. Am ehesten geht launchd von Apple in die Richtung, die Poettering einschlagen will, und so werden Features von launchd auch mehrfach erwähnt.
Die Hauptaufgabe von init ist traditionell, die System- und Benutzerprozesse zu starten. Es ist der erste Prozess, der vom Kernel gestartet wird, und hat daher die feste Prozess-ID 1. Das Ziel von systemd ist, den Bootvorgang auf das absolute Maximum zu beschleunigen. Dazu müssen möglichst viele Dienste parallel gestartet werden, und nicht essentielle Dienste sollten erst später, eventuell erst wenn sie benötigt werden, gestartet werden.
Die Hauptkritik an SysV-Init ist, dass es von einer ziemlich statischen Systemkonfiguration ausgeht und nichts parallel ausführt. In dieser Hinsicht ist es längst obsolet. Wenn man allerdings Dienste parallel starten will, muss man Abhängigkeiten berücksichtigen. So benötigt Avahi D-Bus, und CUPS benötigt Avahi. Bevor CUPS starten kann, muss zu erst D-Bus und dann Avahi gestartet werden. Eine von Poetterings zentralen Ideen ist es nun, diese Abhängigkeiten vom System selbst auflösen zu lassen, anstatt sie explizit anzugeben.
Der erste Baustein hierfür ist die Verbindung mit Netzwerk-Sockets. Wenn ein Daemon einen anderen benötigt, bedeutet dies meist, dass er voraussetzt, dass er sich mit einem bestimmten Socket verbinden kann. systemd muss nur dafür sorgen, dass der Socket bereits geöffnet ist, dann muss der anfordernde Prozess nicht mehr pausieren. Er würde nur dann blockieren, wenn er eine Kommunikation mit dem anderen Daemon ausführt und der andere Daemon noch nicht gestartet ist. Der andere Daemon kann, wenn er nicht sowieso bereits in der Startphase ist, automatisch gestartet werden. Die Verbindungspuffer des Kernels helfen dabei, da sie dafür sorgen, dass keine Verbindungsanforderung verloren geht. Sobald der andere Daemon gestartet ist, erhält er von systemd den bereits geöffneten Socket. Diese Idee stammt aus Apples launchd, sie beruht aber im Kern auf dem bekannten Konzept von inetd.
Wenn in den Start der Daemonen D-Bus involviert ist, wird die Situation noch einfacher, denn D-Bus besitzt bereits Mechanismen, um Dienste auf Anfrage zu aktivieren. Zusammenfassend können alle Daemonen, die Sockets oder D-Bus benötigen, parallel gestartet werden, da die Abhängigkeiten automatisch aufgelöst werden.
Gelegentlich ist es auch erforderlich, auf das Einhängen von Dateisystemen zu warten. Wenn beispielsweise /usr ein eigenes Dateisystem ist, muss sichergestellt sein, dass es vor dem ersten Zugriff auf /usr gemountet ist. Das kann sich aber verzögern, sogar für recht lange Zeit, falls eine Dateisystemprüfung nötig ist. Ähnliches gilt für Netzwerk-Dateisysteme. Auch hier gibt es eine Lösung, um die ansonsten komplexen Abhängigkeiten automatisch aufzulösen: autofs. autofs wird allerdings in keiner Distribution standardmäßig genutzt. Nach Poetterings Untersuchungen ist autofs aber sehr gut für diesen Zweck brauchbar. Bedenken, dass autofs zu »fragil« oder ein Hack sei, seien demnach nicht gerechtfertigt.
Die Verwendung von Shell-Skripten für den ganzen Startvorgang ist laut Poettering eine weitere Ursache für Ineffizienz. Zahlreiche externe Programme müssen immer wieder aufgerufen werden. Teile davon sollten, so Poettering, durch C-Programmcode in systemd ersetzt werden. Allerdings glaubt auch Poettering nicht, dass es möglich ist, auf Skripte ganz zu verzichten. Es sei nicht unbedingt immer sinnvoll, daher werden Skripte auch weiterhin unterstützt werden müssen.
Eine weitere Funktion des init-Programms ist es, Prozesse zu überwachen und gegebenenfalls neu zu starten. In der Praxis funktionert das aber nicht immer, da gestartete Daemonen manchmal forken und init die ID des neuen Prozesses nicht kennt. Abhilfe schaffen für Poettering die Control Groups, eine neuere Funktion des Linux-Kernels, die für die Verwaltung von Containern, einer Form von virtuellen Maschinen, geschaffen wurde. Control Groups existieren jetzt schon mindestens zwei Jahre, ältere Kernel ohne diese Funktionalität werden von systemd nicht unterstützt. Mit Control Groups wird es auch möglich, jedem Prozess eine genau definierte Umgebung zu geben.
Die Implementation von systemd ist bereits weit fortgeschritten und wurde auf das Konzept von Units aufgebaut. Es existieren sieben Typen von Units, von denen Service, Socket, Device, Mount und Automount bereits weitgehend aus den obigen Erklärungen hervorgehen. Zusätzlich wurde »Target« implementiert, das es ermöglicht, mehrere Units zu einer Einheit zusammenzufassen. Ein Beispiel ist multi-user.target, das von allen Diensten abhängt, die von einem laufenden System benötigt werden, vergleichbar mit dem bisherigen Runlevel 5. Die letzte Unit ist »Snapshot«, mit dem sich der Systemzustand speichern und wiederherstellen lässt.
Der Quellcode von systemd kann aus dem Versionsverwaltungssystem von Poettering heruntergeladen werden. systemd kann als Ersatz für SysV-init und Upstart verwendet werden, ohne die Konfiguration ändern zu müssen. Zum Ausprobieren steht auch eine virtuelle Maschine mit Fedora 13 für Qemu bereit. Zur grafischen Verwaltung von systemd steht analog zu entsprechenden Tools für Sysv-Init und Upstart das Programm systemadm zur Verfügung.
Die Entwickler sehen in systemd nicht nur einen Ersatz für bisherige init-Systeme, den sie so bald wie möglich in die Distributionen (zumindest Fedora und openSUSE) bringen wollen. systemd will auch eine allgemeine Sitzungsverwaltung wie gnome-session oder kdeinit ersetzen, da sich die Funktionen ähneln. Geplant sind auch zwei neue Unit-Typen, eine für automatisches Einbinden von Swap-Geräten und einen Timer, der den Cron-Daemon ersetzen könnte. Diese Ideen sind bereits teilweise implementiert.
){kind=small}
