Kernel-Panics und Absturzdaten unter Linux: Journal des vorherigen Boots, pstore und netconsole

Worum es geht

Wenn ein Linux-System einen Panic erleidet und neu startet oder nach einem Hänger per Power-Cycle neu gestartet wird, liegen die Hinweise an mehreren Orten, die sich darin unterscheiden, wie gut sie einen Absturz überstehen:

• Journal des vorherigen Boots: Ist der Speicher von journald persistent (Storage= in journald.conf), bleiben die bis zum Absturz geschriebenen Meldungen auf dem Datenträger erhalten. journalctl -b -1 -k wählt den vorherigen Boot (-b -1) und nur Kernel-Meldungen (-k/--dmesg: "Show only kernel messages"). Dies zuerst prüfen; ausser einem persistenten Journal ist keine besondere Konfiguration nötig.
• pstore: Das pstore-Subsystem des Kernels schreibt einen Oops- oder Panic-Eintrag in ein kleines persistentes Backend, bevor die Maschine ausfällt. Mögliche Backends sind ramoops (ein per Kernel-Parameter oder Device Tree reservierter RAM-Bereich, der einen Warmstart, aber keinen Stromausfall übersteht), UEFI-Variablen oder der Speicher der Plattform-Firmware. Es funktioniert nur, wenn ein solches Backend vorhanden und aktiviert ist. Nach dem nächsten Boot erscheinen die Einträge als Dateien unter /sys/fs/pstore/; ist systemd-pstore.service aktiviert, schreibt der Dienst sie ins Journal und verschiebt sie standardmässig nach /var/lib/systemd/pstore/.
• netconsole: ein Kernel-Modul (oder fest eingebauter Treiber), das Kernel-Logmeldungen in Echtzeit per UDP an einen lauschenden Rechner sendet. Es wird mit einem netconsole=-Parameter der Form [src-port]@[src-ip]/[dev],[tgt-port]@<tgt-ip>/[tgt-mac] konfiguriert. Da es Meldungen sendet, sobald sie entstehen, kann es einen Panic erfassen, der den lokalen Speicher nie erreicht. Dafür braucht es einen Netzwerktreiber, der zum Zeitpunkt des Panics noch funktioniert, einen Netzwerkpfad und einen bereits laufenden Empfänger; die UDP-Zustellung ist nicht garantiert.
• kdump, in dieser Serie an anderer Stelle behandelt, ist wieder etwas anderes: Nach einem Absturz startet es per kexec einen zweiten, reservierten Kernel und schreibt für die spätere Analyse einen vollständigen Speicherabzug (vmcore) statt eines Log-Auszugs.

Warum es wichtig ist

Jede Quelle beantwortet eine andere Frage. Das Journal zeigt in vertrautem Format, was bis zum Absturz protokolliert wurde. pstore übersteht Abstürze, die so früh oder so schwerwiegend sind, dass nichts mehr auf den Datenträger geschrieben wurde, enthält aber nur einen kleinen, begrenzten Eintrag. netconsole übersteht einen nicht mehr reagierenden lokalen Datenträger, benötigt aber die Netzwerkschnittstelle und einen Empfänger. kdump liefert das vollständigste Bild, setzt aber eine vorherige Einrichtung voraus und ist für seltene Panics vergleichsweise aufwendig.

So wird es angewendet

• Nach jedem unerklärten Neustart mit journalctl -b -1 -k --no-pager beginnen; ein leeres Ergebnis oder eine kurze Boot-Liste bedeutet, dass das Journal für diesen Boot nicht persistent war.
• Nach einem Absturz /sys/fs/pstore/ und /var/lib/systemd/pstore/ prüfen (Lesezugriff erfordert root), auch wenn das Journal nichts enthält; ein Eintrag dort ist ein direkter Beleg, dass pstore den Panic erfasst hat.
• netconsole vorab auf Systemen einrichten, bei denen sich Panics sonst schwer diagnostizieren lassen, und auf einen Rechner richten, auf dem bereits ein Empfänger läuft.
• kdump für Systeme vorsehen, bei denen ein vollständiger Crash-Dump den Speicher- und Einrichtungsaufwand rechtfertigt, nicht bloss deshalb, weil pstore oder netconsole ebenfalls konfiguriert sind.

Stolpersteine

• Annehmen, das Journal habe etwas aufbewahrt: Mit Storage=auto und ohne Verzeichnis /var/log/journal/ ist es flüchtig, und -b -1 zeigt schlicht nichts an. mkdir -p /var/log/journal gefolgt von systemctl restart systemd-journald macht es ab dann persistent.
• Alte Einträge in /sys/fs/pstore/ liegen lassen, wo sie niemand archiviert: Die Backends sind klein (insbesondere der UEFI-Variablenspeicher), und ramoops überschreibt ältere Einträge. Daher nach jedem Vorfall die Einträge kopieren und löschen.