Debugging Lock-Up - System verliert meine Protokolle

Seit ich unter Arch Linux auf systemd "aktualisiert" habe, verliere ich immer wieder Protokolle, wenn eine unerwartete Sperrung auftritt. Ich bin vor einem Monat auf dasselbe Problem mit dem Verlust von Protokollen gestoßen und habe das Problem einfach erneut festgestellt. Es gibt auch unabhängige andere Bestätigungen .

Situation:

• Während ich einige Dinge in Java und mit netzwerkbezogenen Dienstprogrammen erledigte, sah ich, dass KDE (die Uhr) eingefroren war. Der CPU-Lüfter wurde laut und die Hitze stieg. Der Mauszeiger konnte jedoch noch bewegt werden.
• Ich habe versucht, von einem anderen Computer aus zu ssh (fehlgeschlagen aufgrund "keine Route zum Host")
• Ich wartete ein paar Minuten, vielleicht konnte der NMI-Wachhund die beleidigende Aufgabe beenden. Kein Würfel.
• Ctrl+ Alt+ F1hat auch nach SysRq+ nicht funktioniertR
• Da die obigen Schritte nicht funktionierten, entschied ich mich, die SysRq-Sequenz REI auszugeben. Danach Ewurde der Bildschirm schwarz, aber auch keine Konsole. Nicht einmal nach SysRq+K
• Diese Sitzung scheint also verloren zu sein. Das einzige, was getan werden kann, ist das Sammeln von Debugging-Informationen. Als ich mir Wikipedia ansah , entschied ich mich unter anderem, SysRq+ d(Display gehaltene Sperren) zu drücken .
• Nach dem Drücken von SysRq+ habe Sich eine Sekunde gewartet und dann mit SysRq+ neu gestartet B.
• Nach dem Neustart und der Anmeldung an einer Konsole sah ich keine Spuren eines Absturzes. Der zuletzt protokollierte Eintrag stammte von Wireshark, es gab jedoch noch eine Lücke von 45 Minuten.

(Ich habe Linux v3.8-rc5-218-ga56e160 übrigens ausgeführt)

Wie kann ich also sicherstellen, dass meine Protokolle beim abnormalen Neustart aufgrund einer Blockierung beibehalten werden?

Also habe ich auf dem # systemd IRC-Kanal nachgefragt und es stellt sich heraus, dass journald (der Protokollierungsdämon von systemd) die Protokolle überhaupt nicht regelmäßig auf die Festplatte leert. Dies bedeutet, dass Ihre Protokolle jederzeit gefährdet sind.

Durch das Senden SIGUSR2an die journaldProtokolle werden Protokolle auf die Festplatte geschrieben. Wenn Sie dies jedoch mehrmals tun, werden viele Dateien erstellt. (Die Option wird tatsächlich als "Protokollrotation" beschrieben.)

Am Ende entschied ich mich für einen anderen Vorschlag: die Verwendung eines dedizierten Syslog-Daemons zum Sammeln von Kernel-Protokollen. Da rsyslog vorgeschlagen wurde (und ich bereits Erfahrung damit hatte), habe ich diese Option weiter untersucht. Ich habe im Arch Wiki einige weitere Details zur Verwendung von rsyslog geschrieben.

Die Idee ist, rsyslog auszuführen und nur Daten von der Kernel-Einrichtung zu sammeln. Da rsyslog von liest /proc/kmsg(was nur einen einzigen Leser erlaubt) und journald von liest /dev/kmsg(mehrere Leser erlaubt), verlieren die Dämonen auf keinen Fall Protokolle (sehr wichtig für mich!). Konfigurieren Sie rsyslog so, dass Kernel-Nachrichten in eine Datei geschrieben werden, und stellen Sie sicher, dass diese Datei gedreht wird, um zu verhindern, dass Ihr Speicherplatz belegt wird.

Diese Lösung ist nicht perfekt:

• Andere Protokolle (z. B. von NetworkManager) gehen verloren. Dies könnte gelöst werden, indem mehr Protokolle von Syslog an Journald weitergeleitet werden (dies bedeutet Duplizierung!).
• Duplizieren von Protokollen. Die Kernel-Nachrichten werden in zwei Dateien geschrieben. Dies ist kein Problem. Im Allgemeinen ist die Anzahl der Protokolle gering und Sie möchten lieber mehr Kopien der Protokolle als keine. Sie können auch schnelle Tools wie grepdie einzelne Protokolldatei oder die langsamere, aber schickere verwenden journalctl.

Es gibt ein TODO-Element zum häufigeren Löschen von Protokollen, das jedoch immer noch nicht zuverlässig genug ist:

Journal: Senden Sie ab und zu Markierungsnachrichten und synchronisieren Sie diese sofort mit fdatasync (), um stündlich garantierte Synchronisierungen zu erhalten.

Hoffentlich erhält systemd / journald jetzt die Option, die Protokolle auf die Festplatte zu schreiben, aber in der Zwischenzeit können wir Tools kombinieren, um das Ziel zu erreichen.

Es gibt zwei Updates:

1. Hoffentlich erhält systemd / journald jetzt die Option, die Protokolle auf die Festplatte zu schreiben, aber in der Zwischenzeit können wir Tools kombinieren, um das Ziel zu erreichen.

Es gibt eine Option --sync:

Fordert den Journal-Daemon auf, alle noch nicht geschriebenen Journaldaten in das Sicherungsdateisystem zu schreiben und alle Journale zu synchronisieren. Dieser Aufruf wird erst zurückgegeben, wenn der Synchronisierungsvorgang abgeschlossen ist. Dieser Befehl garantiert, dass alle Protokollnachrichten, die vor dem Aufruf geschrieben wurden, zum Zeitpunkt der Rückgabe sicher auf der Festplatte gespeichert werden.

--syncverfügbar seit v228:

journalctl hat einen neuen "--sync" -Schalter erhalten, der den Journal-Daemon auffordert, alle bisher ungeschriebenen Protokollnachrichten auf die Festplatte zu schreiben und die Dateien zu synchronisieren, bevor er zurückkehrt.

2. Es stellt sich heraus, dass journald (der Protokollierungsdämon von systemd) die Protokolle überhaupt nicht regelmäßig auf die Festplatte leert. Dies bedeutet, dass Ihre Protokolle jederzeit gefährdet sind.

man journald.conf(5) sagt:

SyncIntervalSec =

Das Zeitlimit vor dem Synchronisieren von Journaldateien mit der Festplatte. Nach der Synchronisierung werden Journaldateien in den Status OFFLINE versetzt. Beachten Sie, dass die Synchronisierung unbedingt sofort nach der Protokollierung einer Protokollnachricht mit der Priorität CRIT, ALERT oder EMERG erfolgt. Diese Einstellung gilt daher nur für Meldungen der Stufen ERR, WARNING, NOTICE, INFO, DEBUG. Das Standardzeitlimit beträgt 5 Minuten.

SyncIntervalSec=verfügbar seit v199:

journald leert die Journaldateien jetzt spätestens 5 Minuten nach jedem Schreibvorgang explizit auf die Festplatte. Die Datei wird dann auch bis zum nächsten Schreibvorgang offline markiert. Dies sollte die Zuverlässigkeit im Falle eines Absturzes erhöhen. Die Synchronisationsverzögerung kann über SyncIntervalSec = in journald.conf konfiguriert werden.

Siehe auch:

Journald: SIGTERM / SIGINT mit niedriger Priorität versenden

Stellen Sie sicher, dass alle in der Warteschlange befindlichen Protokolldaten vor dem Beenden verarbeitet werden, damit beim Herunterfahren keine unnötigen Nachrichten verloren gehen.