Linux-Tutorial / Linux-Fehler mit Protokollen untersuchen
Um einen Ausfall zu untersuchen, identifizieren Sie den betroffenen Dienst und die Zeit, sammeln Sie verwandte Einträge aus demselben Bootvorgang und derselben Zeitzone und vergleichen Sie sie mit einer Reproduktion. Eine ERROR-Zeile oder nur die letzte Nachricht reicht nicht aus, um die Ursache festzustellen.
Überprüfen Sie den grundlegenden Dienststatus in der Einführung zu systemd. Diese Lektion korreliert Zeiten, Zustände und Protokolle; wenden Sie die Methode in einer kontrollierten Umgebung mit Fehler- und Wiederherstellungsübungen an.
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.
Notieren Sie das Symptom, die Zeit und die letzten Änderungen
Ersetzen Sie „der Server ist kaputt“ durch eine präzise Beobachtung wie „HTTPS-Anfragen von Client A haben seit 14:03 Uhr 502 zurückgegeben.“ Vergleichen Sie die Uhren und Zeitzonen von Client und Server und protokollieren Sie den zuletzt bekannten guten Zustand sowie kürzliche Deployments, Konfigurationsänderungen oder Neustarts. Halten Sie beobachtete Fakten von Hypothesen getrennt.
date --iso-8601=seconds timedatectl systemctl --failed journalctl --list-boots
Wenn ein vorheriger Neustart fehlt, wurde dessen Journal möglicherweise nicht aufbewahrt oder wurde entfernt. Überprüfen Sie flüchtigen versus persistenten Speicher und Aufbewahrungsgrenzen. Fehlende Einträge beweisen nicht, dass kein Fehler aufgetreten ist, und eingeschränkte Berechtigungen können relevante Aufzeichnungen verbergen.
Filtern Sie das Journal nach Dienst, Neustart und Zeit
Ersetzen Sie NAME.service durch die tatsächliche Einheit. Überprüfen Sie den Status, lesen Sie ihr aktuelles Boot-Journal und verengen Sie dann das Zeitfenster. Ein fokussiertes gespeichertes Intervall ist leichter zu vergleichen als ein unbegrenzter Strom von nicht verwandten Nachrichten.
systemctl status NAME.service --no-pager journalctl -b -u NAME.service --since "30 minutes ago" --no-pager journalctl -b -p warning --since "30 minutes ago" --no-pager journalctl -k -b --since "30 minutes ago" --no-pager
-u wählt eine Einheit aus, -b einen Bootvorgang und -k Kernel-Nachrichten. -p warning umfasst Warnungen und schwerwiegendere Prioritäten, aber eine Anwendung kann Einträge inkonsistent kennzeichnen oder Hinweise als gewöhnliche Standardausgabe schreiben. Vergleichen Sie das ungefilterte Intervall nach der Verwendung von Prioritäts-Filtern.
Finden Sie ein absichtlich erstelltes Logger-Ereignis
Das Folgende schreibt zwei markierte Nachrichten, ohne einen Dienst zu ändern. Es erfordert eine Linux-Umgebung, in der Logger-Ausgaben im Journal gesammelt werden. Eingeschränkte Container oder Systeme ohne Syslog-Socket können sich anders verhalten; überprüfen Sie den Sammelpfad, bevor Sie ein leeres Ergebnis interpretieren.
tag="linux-course-log-$(id -u)" logger -t "$tag" "stage=start case=practice" logger -p user.warning -t "$tag" "stage=check result=sample-warning" journalctl -t "$tag" --since "5 minutes ago" --no-pager
Finden Sie beide Nachrichten und deren Zeitstempel, dann fügen Sie -p warning hinzu und prüfen Sie, ob die Nachricht mit normaler Priorität ausgeschlossen wird. Die Beispielwarnung wird absichtlich erzeugt, ist kein echter Vorfall. Verwenden Sie bei Bedarf autorisierte Journal-Leseprivilegien; löschen Sie niemals Produktionsprotokolle oder starten Sie die Sammlung neu, nur um die Übung durchzuführen.
Setzen Sie die Nachrichten mit unabhängigen Nachweisen in Beziehung
| Hinweis | Unabhängige Überprüfungen |
|---|---|
| Zugriff verweigert | Eigentum, Pfadberechtigungen, SELinux-Labels |
| Kein Speicherplatz auf dem Gerät | df -h und df -i auf dem betroffenen Mount |
| Adresse bereits verwendet | Socket-Eigentum und doppelte Prozesse |
| Verbindung verweigert oder Zeitüberschreitung | Listener, Route, Filterung, Abhängigkeit |
| Wiederholter Neustart oder Fehler | Einheitskonfiguration, Exit-Status, aktuelle Bereitstellung |
Eine Meldung über vollen Speicherplatz kann den Zielpfad der Anwendung betreffen und nicht nur das Laufwerk, auf dem das Log gespeichert wird. Eine Berechtigungsverweigerung kann aus dem Durchlaufen des übergeordneten Verzeichnisses oder aus Richtlinien resultieren, nicht nur aus dem Dateimodus. Prüfen Sie die tatsächlich referenzierte Ressource, statt das Problem mit Root-Ausführung oder weltweit beschreibbaren Berechtigungen zu kaschieren.
Dateilogfiles und Aufbewahrung prüfen
Anwendungen können Dateien unter /var/log oder an einen zentralen Collector protokollieren, anstatt das Journal zu nutzen. Bestätigen Sie den konfigurierten Pfad, bevor Sie tail oder grep verwenden. Berücksichtigen Sie bei Bedarf auch rotierte und komprimierte Aufzeichnungen und vereinheitlichen Sie Zeitstempelformate sowie Zeitzonen. journalctl --disk-usage meldet die Nutzung des Journal-Speichers.
Das Löschen oder Bereinigen von Protokollen während einer Untersuchung kann Beweise zerstören. Bewahren Sie das benötigte Intervall in zugriffskontrolliertem Speicher auf und schwärzen Sie Tokens, Cookies, persönliche Daten und private Adressen, bevor Sie es weitergeben. Zeichnen Sie die Ursache, die gezielte Änderung, den wiederholten Test und die verbleibende Unsicherheit auf und bewahren Sie die Beweise gemäß den Richtlinien auf.
