Lahme Dienste bloßstellen

Da Systemd den Bootprozess recht früh kontrolliert, kann es ihn auch umfassend protokollieren und analysieren. So verrät ein Aufruf von "systemd-analyze", wie lange der letzte Startvorgang insgesamt gedauert hat. "systemd-analyze blame" zeigt detailliert an, welcher Dienst wie lange für seinen Start benötigt (Bild 3). Besonders langsame Dienste stehen dabei in der Liste weiter oben. Der folgende Befehl zeichnet die Startdauer der Dienste in eine Zeitleiste ein:

systemd-analyze plot > bootchart.svg

Die fertige Grafik landet dabei in der Datei »bootchart.svg« (Bild 4). Sofern die Software Graphviz installiert ist, erstellt der folgende Befehl einen Dependency Graph:

systemd-analyze dot | dot -Tsvg > abhaengigkeiten.svg

In ihm sind alle gestarteten Dienste und ihre jeweiligen Abhängigkeiten eingezeichnet. Mit diesen grafischen Darstellungen lassen sich bremsende Dienste recht schnell entlarven. Sowohl der Graph als auch die Zeitskala sind allerdings bei Desktop-Systemen recht groß, Administratoren sollten daher einen Bildbetrachter mit Zoom-Funktion verwenden. Immerhin hebt "systemd-analyze" trödelnde Dienste farblich hervor.

Wer nur am Pfad mit den zeitkritischen Diensten interessiert ist, kann ihn sich für das aktuelle Target mit "systemd-analyze critical-chain" direkt an der Konsole ausgeben lassen. Wie lange ein Dienst zum Starten benötigt hat, steht dabei hinter dem "+". Neben dem "@" notiert das Tool, zu welchem Zeitpunkt Systemd den Dienst aktiviert beziehungsweise gestartet hat.

Bild 4: "systemd-analyze" kann auch eine solche Zeitleiste erstellen. Je länger dabei der Balken ist, desto länger hat der Start der jeweiligen Unit gedauert.

Umgang mit Altlasten

Viele Entwickler legen ihren Diensten und Systemprogrammen nur ein SysV-Init Start-Skript bei. Das betrifft vor allem kommerzielle Software. Systemd kann diese Skripte weiterhin auswerten und aufrufen. Intern erstellt Systemd für jedes der Skripte eine entsprechende Service-Unit. In der Ausgabe von "systemctl" tragen solche Units das Kürzel "LSB" oder "SYSV" vor ihrer Beschreibung. Systemd ignoriert allerdings das SysV-Init-Skript, wenn eine Unit-Datei mit dem gleichen Namen existiert.

Systemd versteht zudem weiterhin die alten Runlevel. Wer etwa unter CentOS 7 am Bootprompt noch den Parameter "single" anhängt, landet in einem minimalen Rettungssystem. Systemd wertet die Angabe aus und startet dann automatisch das Target "rescue.target". Analog interpretiert Systemd auch die übrigen Runlevel: Der Aufruf von "telinit 3" aktiviert das Target "multi-user.target" und somit ein System ohne grafische Benutzeroberfläche. Zusätzlich definiert Systemd noch die Targets "runlevel0.target" bis "runlevel6.target", die den jeweiligen alten Runlevels entsprechen. In zukünftigen Systemd-Versionen könnten diese Krücken jedoch verschwinden, Administratoren sollten sie folglich nur im Notfall nutzen.