Linux-Tutorial / Systemd-Dienste, Startvorgang und Protokolle verstehen

Auf einem Linux-System, das systemd verwendet, verläuft der Bootvorgang vom Firmware- und Bootloader zum Kernel; dann aktiviert systemd Dienste und andere Units. Um einen Dienst zu untersuchen, verwenden Sie systemctl, um sowohl seinen aktuellen Status als auch seine Boot-Zeit-Aktivierung zu überprüfen, und verwenden Sie journalctl, um Protokolle vom selben Bootvorgang zu lesen. Jetzt aktiv zu sein und für den Bootvorgang aktiviert zu sein, sind unterschiedliche Zustände.

Dies ist eine Einführung in den Dienstzustand, den Startvorgang und die Aktivierung. Fehleruntersuchung anhand von Protokollen kombiniert mehrere Arten von Beweisen, um eine Ursache einzugrenzen.

Systemkonfigurationsübungen verwenden eine herkömmliche Ubuntu 26.04 LTS oder Rocky Linux 9 VM als Referenzumgebung. Container, WSL und andere Versionen können sich in Dienst- und Paketkonfiguration unterscheiden. Bereiten Sie die Konsolenwiederherstellung vor und zeichnen Sie Ihre Versionen mit der virtuellen Maschinen-Einrichtungslektion auf.

Verstehen Sie die Hauptphasen des Bootvorgangs

Ein typischer PC oder Server beginnt damit, dass die Firmware die Hardware initialisiert und einen Bootloader findet. Der Bootloader lädt den Kernel und die benötigte frühe Umgebung. Der Kernel bereitet Geräte, Speicher und Prozesse vor, woraufhin ein Initialisierungssystem die Userspace-Dienste verwaltet. Diese Lektion gilt, wenn systemd PID 1 ist. Ein Container oder eine Distribution, die ein anderes Init-System verwendet, kann andere Befehle und Erklärungen benötigen.

ps -p 1 -o pid,comm,args
systemctl get-default

Verwenden Sie COMMAND oder ARGS im ersten Ergebnis, um zu prüfen, ob PID 1 systemd ist. In einem Container oder einer spezialisierten Umgebung kann dies unterschiedlich sein. Der zweite Befehl zeigt das Standardziel an. Zum Beispiel steht multi-user.target häufig für ein Mehrbenutzer-Non-Graphical-Ziel; graphical.target kann ein grafisches Ziel darstellen. Ein Ziel gruppiert Einheiten. Das bedeutet nicht, dass alle Dienste nacheinander in einer einzigen Reihenfolge gestartet werden.

Verstehen Sie systemd-Einheiten und Abhängigkeiten

systemd stellt verwaltete Objekte als Einheiten dar. Eine .service-Einheit verwaltet einen Dienst; eine .target gruppiert Einheiten zu einem Ziel; eine .socket kann socketbasierte Aktivierung bereitstellen; und eine .timer plant eine Aktion. Das Paket und die Einheit eines Dienstes müssen tatsächlich installiert sein. Raten Sie nicht den Namen einer Einheit und starten oder stoppen Sie sie nicht auf einer Produktionsmaschine.

Die Startreihenfolge folgt den Abhängigkeiten der Einheiten und den Ordnungsregeln, nicht einer einfachen numerischen Reihenfolge. Eine Regel, die eine Einheit nach einer anderen startet, macht diese nicht automatisch zu einer erforderlichen Abhängigkeit. Einige Einheiten laufen parallel, sodass die Reihenfolge einer angezeigten Liste allein die Ursache eines langsamen Starts nicht bestimmen kann.

systemctl list-units --type=service --state=running
systemctl --failed

Der erste Befehl listet geladene, laufende Serviceeinheiten auf; der zweite listet Einheiten in einem fehlerhaften Zustand auf. Eine leere Fehlerliste beweist nicht, dass eine Anwendung korrekt reagiert. Auch deren Endpunkt, Port oder eigene Protokolle müssen möglicherweise überprüft werden.

Aktuellen Zustand und Aktivierung beim Booten unterscheiden

active betrifft, ob eine Einheit derzeit aktiv ist. enabled bedeutet normalerweise, dass ein Installationslink erstellt wurde, damit sie beim Booten mit einem Ziel starten kann. Ein Service kann active, aber disabled, oder enabled, aber derzeit fehlerhaft sein. Eine static-Einheit kann keine Installationsregel für direkte Aktivierung haben und trotzdem laufen, weil eine andere Einheit sie benötigt oder aktiviert.

NAME.service in der Tabelle ist ein Platzhalter: Ersetzen Sie ihn durch eine Einheit, die auf Ihrem System existiert. Das Stoppen einer kritischen Einheit wie des für den Fernzugriff genutzten SSH-Dienstes kann die Verbindung trennen. Prüfen Sie die Auswirkungen und einen Wiederherstellungsweg, bevor Sie einen Produktionsdienst ändern.

Einen Dienst mit nur lesenden Befehlen prüfen

systemd-journald.service ist auf systemd-Systemen üblich, obwohl ein minimales oder spezialisiertes Image sich anders verhalten kann. Diese Befehle prüfen nur den Zustand.

systemctl status systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

status kann Ladeinformationen, aktuellen Zustand, Prozesse und aktuelle Journal-Einträge anzeigen. is-active kann active, inactive oder failed melden und kann einen ungleich null Rückgabestatus zurückgeben, wenn es inaktiv ist. is-enabled kann enabled, disabled oder static unter anderem melden. Behandeln Sie static nicht als Fehler an sich.

Befehle, die man kennen sollte, bevor man einen Dienst ändert

Wenn eine Änderung erforderlich ist, beeinflussen start und stop den aktuellen Zustand, während enable und disable die automatische Aktivierung betreffen. restart stoppt und startet einen Dienst und kann Verbindungen oder Arbeiten unterbrechen. reload fordert einen Dienst auf, die Konfiguration erneut einzulesen, nur wenn dieser Vorgang unterstützt wird; die Wirkung ist dienstspezifisch. enable --now fordert sowohl die Aktivierung als auch einen sofortigen Start an.

Nach dem Erstellen oder Bearbeiten einer Unit-Datei kann daemon-reload erforderlich sein, damit systemd die Unit-Definitionen erneut einliest. Das unterscheidet sich von restart, das einen Anwendungsprozess neu startet, und dem eigenen reload eines Dienstes, der möglicherweise die Anwendungs-Konfiguration erneut einliest. Planen Sie Backups und ein Wartungsfenster, bevor Sie die Konfiguration einer Produktions-Unit oder Anwendung ändern.

Protokolle des aktuellen Starts lesen mit journalctl

Das systemd-Journal kann Nachrichten von Diensten, dem Kernel und anderen Quellen sammeln. -b wählt den aktuellen Start aus, -u wählt eine Einheit aus, und -n 30 fordert die 30 neuesten Einträge an. Ohne entsprechende Berechtigungen sehen Sie möglicherweise nur einige Nachrichten; ein autorisierter Administrator kann den Rest einsehen.

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager
journalctl --list-boots

Der erste Befehl zeigt die neuesten Einträge für diese Einheit während dieses Starts. Der zweite zeigt die neuesten Einträge mit Warnstufe oder höher. Eine Warnung ist nicht unbedingt die Ursache eines Fehlers; beachten Sie deren Zeit und die umgebenden Nachrichten. Wenn --list-boots keinen früheren Start zeigt, kann die Aufbewahrungs- oder Speicherpolitik des Journals bedeuten, dass dessen Protokolle nicht verfügbar sind. Überprüfen Sie, dass ein früherer Start aufgezeichnet ist, bevor Sie versuchen, ihn zu diagnostizieren.

Eine Abfolge zur Diagnose eines Dienstes, der nicht startet

1. Bestätigen Sie den genauen Unit-Namen und ob dessen Paket installiert ist. Manipulieren Sie keine ähnlich benannten Einheiten nach Vermutung.
2. Verwenden Sie systemctl status, um den Ladezustand, den aktuellen Zustand, die Fehlerzusammenfassung und die letzten Nachrichten zu prüfen.
3. Lesen Sie mehr Kontext vom gleichen Boot mit journalctl -b -u. Suchen Sie nach Anzeichen eines Konfigurationsfehlers, von Berechtigungen, eines Portkonflikts oder einer fehlgeschlagenen Abhängigkeit.
4. Überprüfen Sie die relevante Konfiguration, Ressourcen und Abhängigkeiten; erstellen Sie ein Backup, bevor Sie Änderungen vornehmen. Schwächen Sie Berechtigungen nicht pauschal basierend auf einer Log-Zeile.
5. Nachdem die Ursache behoben wurde, führen Sie nur die erforderliche Aktion zu einem akzeptablen Zeitpunkt aus und überprüfen Sie dann is-active und die tatsächliche Reaktion der Anwendung.

Bei langsamem Start kann systemd-analyze critical-chain helfen, einen wichtigen Startpfad aufzudecken. Eine lange einzelne Dauer in systemd-analyze blame beweist für sich genommen nicht, dass die Einheit den gesamten Start verzögert hat. Parallele Ausführung und Abhängigkeiten sind wichtig.

Offizielle Referenzen

Das systemctl(1) Handbuch behandelt den Status und Änderungen von Units. Das journalctl(1) Handbuch dokumentiert Boot-, Unit- und Prioritätsfilter. Das systemd.unit(5) Handbuch beschreibt Units und deren Abhängigkeitsbeziehungen.