Linux: journalctl zeigt kein Protokoll vom letzten Absturz
journalctl -b -1 findet kein vorheriges Boot? Das Journal lag nur im RAM und ist beim Neustart verdampft. So wird es dauerhaft.
Aufwand:
ca. 10 Min.
Voraussetzung:
sudo-Rechte, Terminal
Gilt für:
Linux mit systemd
Das Symptom
Der Rechner ist mitten in der Arbeit eingefroren oder hart neu gestartet. Man
setzt sich hin, tippt routiniert journalctl -b -1, um nachzulesen, was kurz
vorher passiert ist – und bekommt keine Zeile. journalctl --list-boots zeigt
genau einen Eintrag: den aktuellen. Das Journal tut so, als sei der Rechner
gerade zum ersten Mal in seinem Leben gestartet worden.
Die „Layer 8“-Wahrheit
Nichts ist kaputt und niemand hat etwas gelöscht. Das Journal lag nur nie
irgendwo, wo es einen Stromausfall hätte überleben können. systemd-journald
kennt vier Speichermodi, und zwei davon schreiben nicht auf die Platte:
volatile legt alles unterhalb von /run/log/journal ab, also in ein tmpfs im
Arbeitsspeicher, und auto tut genau dasselbe, solange das Verzeichnis
/var/log/journal nicht existiert. Die Existenz eines leeren Verzeichnisses
entscheidet also darüber, ob der nächste Absturz aufgeklärt werden kann oder
nicht. Das ist bitter, aber es ist eine Voreinstellung, keine Bosheit: Ein
Journal im RAM schont Schreibzugriffe und hält Systeme ohne Platte am Leben. Für
einen Arbeitsrechner ist es trotzdem die falsche Wahl, denn Protokolle, die den
Absturz nicht überleben, protokollieren genau den Moment nicht, für den man sie
führt. Der Fehler ist deshalb nicht, dass die Logs weg sind – der Fehler ist,
dass man es erst nach dem Absturz gemerkt hat. Zehn Minuten Konfiguration jetzt
sparen beim nächsten Mal die Raterei.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Prüfen, ob überhaupt frühere Boots im Journal stehen
Der Befehl listet alle Boots, die das Journal kennt, mit Nummer relativ zum aktuellen Start. Steht dort nur eine einzige Zeile mit der Nummer 0, gibt es schlicht nichts Älteres – und kein Filter der Welt fördert es zutage:
journalctl --list-boots
2.
Nachsehen, wo das Journal wirklich liegt
Zwei Verzeichnisse kommen infrage. /run/log/journal ist der flüchtige Ort im tmpfs, /var/log/journal der dauerhafte auf der Platte. Meldet der Befehl für /var/log/journal, dass es die Datei oder das Verzeichnis nicht gibt, ist die Ursache gefunden:
ls -ld /run/log/journal /var/log/journal
3.
Den eingestellten Speichermodus ablesen
Der Wert kann in der Hauptdatei oder in einem Drop-in stehen. Beide Orte sind dokumentiert, Drop-ins gewinnen. Zeilen, die mit einem Rautezeichen beginnen, sind auskommentierte Vorgaben und gelten nicht:
Sauberer als das Ändern der Hauptdatei ist ein eigenes Drop-in – es überlebt Paket-Updates, und man sieht auf einen Blick, was von Hand entschieden wurde. Mit Storage=persistent legt journald die Ablage unterhalb von /var/log/journal selbst an:
sudo mkdir -p /etc/systemd/journald.conf.d
printf '[Journal]\nStorage=persistent\n' | sudo tee /etc/systemd/journald.conf.d/99-persistent.conf
5.
journald die neue Konfiguration beibringen
Der Dienst liest seine Einstellungen nur beim Start. Ohne Neustart des Dienstes schreibt er munter weiter ins tmpfs, und man wundert sich beim nächsten Absturz erneut:
sudo systemctl restart systemd-journald
6.
Kontrollieren, dass jetzt wirklich auf die Platte geschrieben wird
Nach dem Neustart des Dienstes muss das Verzeichnis /var/log/journal existieren – meldet ls es weiterhin als fehlend, hat die Einstellung nicht gegriffen. Der zweite Befehl nennt zusätzlich den Platzbedarf aller Journaldateien zusammen:
ls -ld /var/log/journal
journalctl --disk-usage
7.
Nach dem nächsten Neustart gegenprüfen
Der endgültige Beweis kommt erst nach einem echten Neustart: Ab jetzt muss --list-boots mindestens zwei Einträge zeigen, und der Blick auf das vorherige Boot muss Meldungen liefern statt Leere. Die Option -p err beschränkt die Ausgabe auf Fehler und höher:
journalctl --list-boots
journalctl -b -1 -p err
Häufige Fragen (FAQ)
?Warum ist das Journal nach dem Neustart leer?
Weil es nie auf der Platte lag. systemd-journald kennt vier Speichermodi: volatile, persistent, auto und none. Bei volatile landen die Protokolle ausschließlich im Speicher, nämlich unterhalb von /run/log/journal – und /run ist ein tmpfs, das der Kernel bei jedem Start neu und leer anlegt. Bei auto entscheidet allein die Existenz des Verzeichnisses /var/log/journal: Ist es da, wird persistent geschrieben, fehlt es, verhält sich journald wie bei volatile. Genau deshalb gibt es auf manchen Installationen kein vorheriges Boot – der Absturz hat seine eigene Beweismittelkiste mitgenommen.
?Kann ich die Protokolle des abgestürzten Boots noch retten?
Nein. Was im Arbeitsspeicher stand, ist mit dem Strom weg, daran ändert auch nachträgliches Umstellen nichts. Persistenz wirkt ab dem nächsten Start, nicht rückwirkend. Ein Rest lohnt den Blick: Läuft auf dem System zusätzlich ein klassischer Syslog-Dienst wie rsyslog, schreibt der seine Dateien unterhalb von /var/log direkt auf die Platte – dort kann durchaus noch etwas stehen. Das Journal selbst gibt nichts mehr her, und jede Anleitung, die das Gegenteil verspricht, verkauft dir Zauberei.
?Was ist der Unterschied zwischen Storage=auto und Storage=persistent?
Bei persistent legt journald die Ablage unterhalb von /var/log/journal selbst an, wenn sie fehlt, und weicht nur im frühen Start oder bei nicht beschreibbarer Platte auf /run/log/journal aus. Bei auto legt journald nichts an, sondern schaut nach: Existiert /var/log/journal, verhält es sich wie persistent, sonst wie volatile. Der eingebaute Vorgabewert im Standard-Namensraum ist laut Handbuch persistent – was deine Distribution in ihrer mitgelieferten Konfiguration daraus macht, steht auf einem anderen Blatt. Deshalb der Blick in die Konfiguration, statt zu raten.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.