Bootzeiten optimieren mit systemd: So analysiert man langsame Systeme
Inhaltsverzeichnis:
Lange Startzeiten bei Linux-Systemen sind ein bekanntes Ärgernis im Alltag vieler Nutzer. Besonders bei Servern, die eine hohe Verfügbarkeit benötigen, oder auf Desktop-Systemen, die täglich mehrfach hochgefahren werden, wirkt sich jede gesparte Sekunde merklich aus. Mit der Einführung von systemd haben moderne Linux-Distributionen ein mächtiges Werkzeug erhalten. Dieses verwaltet nicht nur Dienste, sondern ermöglicht auch detaillierte Analysen der Bootzeiten.
Das Besondere an systemd liegt in seiner parallelen Arbeitsweise beim Systemstart. Anders als ältere Init-Systeme startet systemd mehrere Dienste gleichzeitig, wenn deren Abhängigkeiten erfüllt sind. Diese Parallelisierung bringt erhebliche Geschwindigkeitsvorteile, macht aber auch die Analyse komplexer. Glücklicherweise bietet systemd mit dem Kommandozeilenwerkzeug systemd-analyze eine umfangreiche Sammlung von Befehlen, mit denen sich jeder Schritt des Bootvorgangs genau untersuchen lässt.
Die Grundlagen von systemd-analyze verstehen
Das Werkzeug systemd-analyze ist fest in systemd integriert und ermöglicht die Leistungsanalyse des Startvorgangs. Es erfasst präzise Zeitstempel für jeden Dienst, jede Abhängigkeit und jeden Übergang zwischen den verschiedenen Boot-Phasen. Ohne weitere Parameter aufgerufen zeigt der Befehl „systemd-analyze“ eine Übersicht der gesamten Bootzeit und unterteilt diese in Firmware-, Bootloader-, Kernel- und Userspace-Zeiten. Dadurch erkennt man, welche Phase des Bootvorgangs die meiste Zeit verbraucht.
Der grundlegende Befehl „systemd-analyze time“ liefert eine erste Einschätzung der Systemleistung. Er gibt Auskunft darüber, wie viele Sekunden zwischen dem Start des BIOS und dem Erreichen des Userspace vergangen sind. Bei UEFI-Systemen werden zusätzlich die Zeiten für Firmware und Bootloader angezeigt. Diese Informationen bilden die Basis für alle weiteren Optimierungen, weil sie zeigen, ob primär die Hardware-Initialisierung oder die Software-Dienste für Verzögerungen verantwortlich sind.
Services identifizieren, die den Start verzögern
Mit dem Unterbefehl „blame“ zeigt systemd-analyze eine Liste aller gestarteten Dienste sortiert nach ihrer Initialisierungszeit an. Der Befehl „systemd-analyze blame“ listet alle Units in absteigender Reihenfolge auf, beginnend mit jenen, die am längsten zum Starten benötigt haben. Diese sortierte Darstellung macht es leicht, die größten Zeitfresser auf einen Blick zu erkennen. Typische Kandidaten sind Datenbankdienste wie MariaDB oder PostgreSQL, Netzwerkdienste wie NetworkManager-wait-online.service oder auch Desktop-Komponenten bei grafischen Oberflächen.
Die angezeigten Zeitwerte sollten allerdings mit Vorsicht interpretiert werden. Ein Dienst mit langer Initialisierungszeit blockiert nicht zwangsläufig den gesamten Bootvorgang, wenn andere Dienste parallel laufen können. Häufig problematisch sind Services wie NetworkManager-wait-online.service, der tatsächlich wartet, bis eine Netzwerkverbindung hergestellt ist, bevor weitere Dienste starten können. Solche Dienste verlängern die Bootzeiten und sind echte Bremsen im Startprozess, weil sie aktiv andere Units blockieren und keine parallele Ausführung zulassen.
Critical Chain analysieren und Abhängigkeiten verstehen
Die kritische Kette zeigt, welche Units sequenziell aufeinander warten und damit den Bootvorgang direkt verlängern. Der Befehl „systemd-analyze critical-chain“ stellt diese Abhängigkeitskette als Baumstruktur dar, bei der jeder Eintrag zwei Zeitangaben enthält: Nach dem „@“-Symbol steht der Zeitpunkt, zu dem die Unit aktiv wurde, nach dem „+“-Symbol die Zeitspanne, die der Service selbst zum Starten benötigte. Diese Darstellung macht sofort deutlich, wo im Bootprozess die größten Verzögerungen auftreten und welche Dienste für Wartezeiten verantwortlich sind.
Der wesentliche Unterschied zwischen „blame“ und „critical-chain“ liegt im Fokus der Bootzeiten Analyse. Während „blame“ alle Dienste nach ihrer absoluten Startdauer sortiert, konzentriert sich „critical-chain“ auf jene Abhängigkeitsketten, die tatsächlich sequenziell ablaufen müssen. Ein Dienst kann in der blame-Liste weit oben stehen, aber trotzdem irrelevant für die Gesamtbootzeit sein, wenn er parallel zu anderen zeitkritischen Prozessen läuft. Die kritische Kette hingegen zeigt nur die Units, bei denen eine Optimierung direkt die Bootzeiten verkürzt.
Grafische Darstellung des Boot-Prozesses nutzen
Für eine visuelle Analyse erstellt systemd-analyze mit dem Befehl „systemd-analyze plot > boot.svg“ eine Vektorgrafik des gesamten Startvorgangs. Diese SVG-Datei visualisiert jeden gestarteten Dienst als horizontalen Balken auf einer Zeitachse, wobei die Länge des Balkens der Initialisierungszeit entspricht. Die Grafik macht Parallelisierung und Engpässe auf einen Blick erkennbar und zeigt farblich hervorgehoben, welche Dienste auf der kritischen Kette liegen. Mit einem Browser oder Grafikprogramm lässt sich die Datei öffnen und beliebig zoomen, um Details einzelner Services zu untersuchen.
Eine weitere Visualisierungsmöglichkeit bietet der „dot“-Befehl, der die Abhängigkeiten zwischen Services als Graphen darstellt. Mit „systemd-analyze dot | dot -Tsvg > dependencies.svg“ entsteht ein Diagramm, das alle Unit-Beziehungen zeigt. Pfeile zwischen den Units verdeutlichen, welcher Service von welchem anderen abhängt. Diese Darstellung ist besonders hilfreich, wenn man verstehen möchte, warum bestimmte Dienste nicht früher starten können oder welche Abhängigkeiten möglicherweise überflüssig sind.
Services gezielt deaktivieren und maskieren
Nicht benötigte Dienste lassen sich mit systemctl entweder deaktivieren oder für den Bootvorgang maskieren. Der Befehl „systemctl disable servicename.service“ entfernt den symbolischen Link, der den automatischen Start beim Booten bewirkt. Der Service bleibt installiert und kann jederzeit manuell gestartet oder von anderen Diensten aktiviert werden. Diese Methode eignet sich für Services, die nur gelegentlich benötigt werden, aber nicht bei jedem Systemstart laufen müssen.
Das Maskieren mit „systemctl mask servicename.service“ geht einen Schritt weiter und verhindert jegliches Starten des Dienstes, selbst wenn andere Units ihn explizit anfordern. Beim Maskieren erstellt systemd einen symbolischen Link von der Unit-Datei nach /dev/null, was den Service faktisch unbrauchbar macht. Diese drastische Maßnahme sollte nur bei Services angewendet werden, die definitiv nicht benötigt werden. Beispiele für häufig deaktivierbare Dienste auf Desktop-Systemen sind Bluetooth-Services bei Rechnern ohne Bluetooth-Hardware oder Cloud-Sync-Dienste wie snapd bei Nutzern, die keine Snap-Pakete verwenden.
Praktische Optimierungsmaßnahmen umsetzen
Eine systematische Optimierung beginnt mit der Identifikation überflüssiger Dienste durch die bereits beschriebenen Analyse-Tools. Besonders vielversprechend ist die Umstellung von blocking Services auf Socket-Aktivierung. Hier startet der ein Dienst erst dann, wenn man tatsächlich eine Verbindung anfragt. Docker beispielsweise lässt sich so konfigurieren, dass docker.socket aktiv ist, docker.service aber erst bei Bedarf startet. Diese Strategie verkürzt die kritische Kette erheblich, weil der eigentliche Dienst nicht mehr im Bootprozess wartet.
Nach jeder Optimierung sollte eine erneute Messung mit „systemd-analyze time“ erfolgen, um die Verbesserung zu quantifizieren. Weitere Potenziale liegen in der Bereinigung der Journal-Logs mit reduzierten Größenlimits in /etc/systemd/journald.conf oder der Deaktivierung von Plymouth auf Systemen, die ohnehin in unter zwei Sekunden starten. Für fortgeschrittene Optimierungen kann man Kernel-Parameter wie „quiet“ setzen oder initramfs-Hooks minimieren.
Fazit zur Optimierung der Bootzeiten mit systemd
Die Parallelisierung von systemd macht die Analyse zwar komplexer als bei älteren Init-Systemen. Es ermöglicht aber auch deutlich größere Geschwindigkeitsgewinne, wenn Abhängigkeiten intelligent gestaltet werden. Mit etwas Geduld und den richtigen Analysemethoden sparen Anwender selbst bei bereits gut konfigurierten Systemen oft noch einige Sekunden ein, die im täglichen Betrieb einen merklichen Unterschied machen.
