Systemstart mit Systemd unter Linux

Turbobooster

In fast allen großen Linux-Distributionen kümmert sich mittlerweile Systemd um den Systemstart. Der SysV-Init-Ersatz geht nicht nur besonders flott zu Werke, er schmeißt auch die alten kryptischen Startskripte über Bord. Linux-Administratoren müssen deshalb früher oder später umlernen.
Sie ist aufwendig, kostet Geld und bringt in der Regel keinen unmittelbar sichtbaren Nutzen: Die Client-Security. Dabei ist das richtige Absichern von Rechnern ... (mehr)

Den Bootvorgang der meisten Linux-Distributionen steuerte lange Zeit das bewährte, aber etwas unflexible SysV-Init. Wie sein Name andeutet, orientiert es sich am Bootsystem des kommerziellen Unix System V aus den 1980er Jahren. Zunächst startet es ein paar Shell-Skripte, die dann wiederum die benötigten Dienste wecken, das Netzwerk einrichten, Dateisysteme einhängen und weitere vorbereitende Maßnahmen ausführen. Dieses Vorgehen ist zwar einfach, aber auch recht langsam: Zum einen muss die Shell jedes Skript interpretieren, zum anderen müssen die Skripte in einer bestimmten Reihenfolge ablaufen. So kann beispielsweise der Webserver erst starten, wenn das Netzwerk steht.

Beschleuniger Systemd

Einen ordentlichen Geschwindigkeitsschub soll das maßgeblich von Lennart Poettering und Kay Sievers entwickelte Systemd bringen. Obwohl erst 2010 veröffentlicht, hat es bereits das alte SysV-Init in nahezu allen großen Distributionen abgelöst. OpenSUSE bietet Systemd seit Version 12.1 an, in Fedora steht es ab Version 15 zur Verfügung. Zuletzt stellte Red Hat sein neues RHEL 7 auf Systemd um, die nächste größere Debian-Version dürfte ebenfalls standardmäßig Systemd verwenden. Selbst Ubuntu wird sich bald von seiner Eigenentwicklung Upstart verabschieden [1].

Systemd nutzt einige pfiffige Konzepte, um den Systemstart massiv zu beschleunigen. Pate standen dabei vor allem "launchd" aus Mac OS X und die von Sun Solaris verwendete Service Management Facility (SMF).

Parallele Starts

Systemd startet keine Skripte mehr, sondern aktiviert stattdessen selbst die entsprechenden Dienste und Anwendungen. Damit muss Systemd nicht immer wieder den Shell-Interpreter anwerfen, was Zeit und Ressourcen spart. Um abwärtskompatibel zu bleiben, verdaut Systemd aber auch weiterhin die alten SysV-Init-Skripte.

Des Weiteren startet Systemd sämtliche Dienste parallel. Dummerweise reagieren einige Dienste auf dieses Verfahren etwas allergisch. So lässt sich ein Webserver erst dann starten, wenn das Netzwerk eingerichtet und vorhanden ist. Systemd richtet deshalb die zur Kommunikation benötigten Sockets kurzerhand selbst ein und gaukelt dem Webserver so ein funktionierendes Netzwerk vor. Alle über die Sockets verschickten Nachrichten fängt Systemd ab und puffert sie so lange, bis das eigentliche Netzwerk steht beziehungsweise ein benötigter Dienst endlich läuft. Sobald dies der Fall ist, arbeiten die Dienste die in der Warteschlange ausstehenden Anfragen ab. Damit blockiert der Start eines Dienstes nicht den kompletten Bootprozess. Im schlimmsten Fall müssen die Prozesse einen kurzen Moment auf eine Antwort warten. Da Systemd die von ihm eingerichteten Sockets kontrolliert, kann es auch feststellen, ob der darüber kommunizierende Dienst abgestürzt ist, und diesen dann automatisch neu starten. Im Idealfall bleiben dabei sogar die Verbindungen mit den Clients bestehen. Systemd kümmert sich nicht nur um die Kommunikation über Sockets, sondern unter anderem auch um das Einbinden von Dateisystemen und D-Bus-Verbindungen. Mittlerweile ist sogar das Werkzeug Udev, das sich um das Hotplugging von Geräten kümmert, in Systemd aufgegangen [2].

Auf Wunsch startet Systemd die einzelnen Dienste erst dann, wenn sie tatsächlich benötigt werden oder ein vom Administrator vor­ge­gebenes Systemereignis eintritt. Dieses Vorgehen beschleunigt nicht nur den Startvorgang, es spart gleichzeitig auch den alten "inetd"-Dienst ein. Abschließend sperrt Systemd jeden Prozess samt der von ihm gestarteten Kind-Prozesse in eine eigene Control Group. Diese kurz als Cgroups bezeichnete Funktion des Linux-Kernels erlaubt es, den Diensten gezielt den Zugriff auf Ressourcen zu entziehen. Systemd nutzt diese kleinen Gefängnisse vor allem, um die Prozesse kontrolliert zu stoppen: Bei einem Absturz kann Systemd nicht nur den Dienst, sondern auch alle seine Kind-Prozesse bequem aus dem Speicher entfernen.

comments powered by Disqus

Artikel der Woche

Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2018