Das Init-System Systemd, Teil 1
Seite 4: SysV-Kompatibilität, Control Groups
Althergebrachtes
Aus Kompatibilitätsgründen versteht sich Systemd auch mit System-V- und LSB-Init-Skripten, die nicht nur von Sysvinit-Distributionen verwendet werden, sondern auch mit Upstart funktionieren. Diese Init-Skripte werden durch eine Shell interpretiert und erfordern einen Parameter wie "start", "stop" oder "restart".
Auch die Hersteller kommerzieller Software legen ihren Hintergrunddiensten typischerweise Sys-V- und LSB-Init-Skripte bei. Um sie intern wie eine richtige Service-Unit zu behandeln, generiert Systemd daraus automatisch eine Service-Unit; das Init-Tool ignoriert allerdings Sys-V- und LSB-Init-Skripte, wenn es eine Unit-Datei mit gleichem Namen findet.
Gruppen
Systemd packt jeden Dienst beim Start in eine eigene, nach dem Dienst benannte Control Group. Diese Technik isoliert die Prozesse und bietet mit Hilfe optionaler Controller Stellschrauben, um die Verteilung der Ressourcen zu beeinflussen. Kindprozesse erben die Gruppenzugehörigkeit.
Systemd kann so Prozessgruppen als zusammengehörige Einheiten verwalten, um etwa beim Beenden eines Dienstes alle zugehörigen Prozesse zuverlässig zu stoppen. Administratoren können über die normalen Cgroup-Schnittstellen den Ressourcenverbrauch von Diensten kontrollieren; die manuelle Zuordnung der Prozesse entfällt.
Breiterer Ansatz
Systemd liegen eine Reihe von Units bei, die einige grundsätzliche Dinge bei der Initialisierung des Systems erledigen. Teilweise sind diese wie ein Hintergrunddienst angelegt. Die Service-Unit fsck-root.service etwa veranlasst bei Bedarf eine Prüfung des Root-Dateisystems, bevor es durch remount-rootfs.service beschreibbar eingebunden wird. Die Service-Units hwclock-load und hwclock-save sorgen für einen Abgleich der Zeit mit der Systemuhr.
Bei Sysvinit- und Upstart-Distributionen kümmern sich Shell-Skripte um derartige Aufgaben, etwa /etc/rc.sysinit oder eine Sammlung kleiner Skripte in /etc/rcS.d/. Diese Skripte sind stark auf die jeweilige Distributionsfamilie zugeschnitten und verhalten sich daher bei Debian ganz anders als bei Fedora oder OpenSuse; das ist der Grund, warum man bei Fedora und RHEL in /etc/sysconfig/keyboard die Tastatur festlegen kann, dieses Verzeichnis bei Debian aber vergeblich sucht.
Viele Systemd-Units starten C-Programme, die schneller und robuster sein sollen als die Shell-Skipte, die diese Aufgaben bisher erledigten. Mit der Integration dieser Dienste versucht Systemd viele Unterschiede zwischen den Distributionen aus der Welt zu schaffen. Das erleichtert Entwicklern die Arbeit, denn sie können Unit-Dateien für ihre Dienste mitliefern und dabei die Dinge erwarten, die Systemd beiliegen. Sys-V-Init-Skripte beizulegen ist erheblich schwieriger, weil diese auf distributionsspezifische Eigenarten Rücksicht nehmen müssen.
Details
Weitere Hintergründe zu Ideen, Arbeitsweisen und Einsatz von Systemd liefern die Man-Pages zu Systemd – etwa systemd und systemd.conf. Auch für jeden der Unit-Typen gibt es Man-Pages – beispielsweise systemd.unit oder systemd.service. Über die Homepage von Lennart Poettering findet man zahlreiche Artikel, die Hintergründe zum Init-System erläutern, darunter die bislang zwei Teile umfassende Serie "systemd for Developers":
Im dritten "Systemd Status Update" hat Poettering zudem vor Kurzem einige der Neuerungen aufgelistet, die in den letzten eineinhalb Jahren in Systemd eingeflossen sind.
Im zweiten Teil des Artikels geht es um Systemd aus Adminsicht: Aufbau von Unit-Dateien, Befehle zum Auflisten, Starten und Stoppen von Units, Statusausgaben und Beheben von Problemen. (thl) (thl)
