Linux Crash Dumps mit kdump sichern und analysieren

Was kdump beim Kernel-Crash erfasst

kdump bereitet die Sicherung eines Linux-Kernelspeicherabbilds vor, bevor ein Absturz eintritt. Dazu wird beim Start des regulären Kernels ein Speicherbereich reserviert. In diesen Bereich wird ein separater Capture-Kernel geladen, der bei einem geeigneten Crash-Ereignis über kexec gestartet werden kann.

Der Capture-Kernel läuft unabhängig vom abgestürzten Systemkernel und erhält Zugriff auf dessen Speicherabbild über /proc/vmcore. Er kann dieses Abbild an ein konfiguriertes Ziel schreiben. Die gesicherte Datei wird üblicherweise vmcore genannt; ob sie alle ursprünglichen Speicherbereiche enthält, hängt unter anderem von der gewählten Filterung ab.

Die Aufgaben sind getrennt: kdump erfasst und sichert den Zustand, während das Programm crash einen vorhandenen Dump anschließend analysiert. Damit lassen sich etwa Kernelmeldungen und Aufgabenstapel untersuchen. Ein Dump ist dabei eine Momentaufnahme und liefert nicht automatisch die vollständige Vorgeschichte des Fehlers.

Ein Kernel-Oops ist nicht gleichbedeutend mit einer Kernel-Panic: Ein Oops kann auftreten, ohne dass das System unmittelbar in eine Panic übergeht. Deshalb führt nicht jede Kernelstörung zur kdump-Erfassung. Ein Core-Dump einer Anwendung betrifft dagegen den Zustand eines Prozesses und ist kein Kernel-vmcore.

Für die nachträgliche Untersuchung ist diese Vorbereitung entscheidend. War zum Absturzzeitpunkt kein Capture-Kernel vorbereitet oder wurde kein Abbild gesichert, kann kdump den verlorenen Speicherzustand später nicht rekonstruieren. Dann bleiben vorhandene Protokolle und andere über den Neustart erhaltene Diagnosedaten als Ausgangspunkt.

Voraussetzungen und Grenzen der Erfassung

Kläre zuerst Distribution, Version und Architektur des Servers. Davon hängen Paketnamen, Dienststeuerung, Bootkonfiguration und unterstützte Speicherziele ab. Nutze für die Einrichtung die Dokumentation genau dieser Plattform, statt Befehle verschiedener Distributionen zu kombinieren; auch Hardware und installierte Treiber beeinflussen die Anforderungen.

Der Bootparameter crashkernel legt die Speicherreservierung für die Crash-Erfassung fest. Dieser Bereich steht dem normalen Betrieb nicht zur Verfügung. Eine pauschale Größe ist nicht zuverlässig: Orientiere dich an den Vorgaben für Distribution, Architektur und konkrete Ausstattung und berücksichtige den Speicherbedarf des Capture-Systems.

Der reservierte Speicher allein reicht nicht. Der Capture-Kernel muss geladen sein und das konfigurierte Ziel erreichen können. Dafür müssen die benötigten Treiber und Komponenten in seiner Umgebung verfügbar sein; bei einem Netzwerkziel gehören auch die Verbindung und die erreichbare Gegenstelle zu den Voraussetzungen.

Plane am Ziel genügend Kapazität für die erwarteten Abbilder und deren Aufbewahrung ein. Wie groß ein Dump wird, hängt unter anderem vom Speicherinhalt und von der Filterung ab. Ein volles oder nicht erreichbares Ziel kann die Sicherung verhindern, selbst wenn die Reservierung korrekt gesetzt ist.

Auch eine vorbereitete Installation ist keine Garantie für einen verwertbaren Dump. Ein Oops löst nicht zwangsläufig eine Panic aus; bei vollständigem Stromverlust kann der Capture-Kernel nicht mehr arbeiten. Ebenso kann ein schwerer Hardwarefehler seinen Start oder das Schreiben des Abbilds verhindern. Erfassung und Ziel müssen deshalb getrennt von der eigentlichen Fehlerursache betrachtet werden.

Welche Dateien für die Analyse zählen

Für die Untersuchung zählt nicht nur die Dumpdatei. Bewahre möglichst auch die zugehörigen Kerneldateien und Protokolle auf, damit sich der Zustand zum Absturzzeitpunkt mit Meldungen und Änderungen abgleichen lässt. Die folgende Übersicht trennt das eigentliche Speicherabbild von den Hilfsdateien, die seine Auswertung ermöglichen.

Besonders wichtig ist das passende vmlinux: Architektur und exakter Kernel-Build müssen zum abgestürzten Systemkernel gehören. Der nach dem Neustart laufende Kernel kann ein anderer sein. Die Ausgabe von uname -r auf dem neu gestarteten Server genügt daher nicht, um die richtige Datei für den alten Dump auszuwählen.

Verwende außerdem eine mit Kernel und Dumpformat kompatible Version von crash. Sind externe oder zusätzliche Treiber relevant, halte auch deren passende Moduldateien und Debuginformationen bereit. Fehlen Symbole oder wurden benötigte Speicherseiten herausgefiltert, kann die Auswertung eingeschränkt sein; solche Lücken gehören zur Dokumentation des Befunds.

Ein vmcore kann vertrauliche Inhalte aus dem Arbeitsspeicher enthalten. Beschränke deshalb den Zugriff, schütze die Übertragung und lege Aufbewahrungs- und Löschfristen fest. Bevor du einen Dump oder ergänzende Logs an einen Supportdienst weitergibst, kläre die dafür erforderliche Freigabe und den zulässigen Umfang.

kdump auf dem Server vorbereiten

Ausgangspunkt sind Distribution, Version und Architektur des Servers. Prüfe in deren Dokumentation, welche Pakete für kdump und das Laden des Capture-Kernels benötigt werden und wie der Dienst eingerichtet wird. Anleitungen für unterschiedliche Distributionen sind nicht beliebig austauschbar: Paketnamen, Bootkonfiguration und Prüfwerkzeuge können sich unterscheiden.

Zur Vorbereitung gehört die passende Speicherreservierung über den Bootparameter crashkernel. Wähle Größe und gegebenenfalls weitere Einstellungen nach den Vorgaben für die konkrete Plattform und Hardware. Der reservierte Speicher fehlt dem regulär laufenden System; eine universelle Größenangabe wäre deshalb ebenso wenig hilfreich wie eine ungeprüfte Übernahme von einem anderen Server.

Nach der plattformspezifischen Bootkonfiguration und einem gegebenenfalls nötigen Neustart zeigt der folgende lesende Shell-Befehl die Parameter des aktuell laufenden Kernels. Suche in der Ausgabe nach crashkernel. Ein Eintrag zeigt die übergebene Einstellung, beweist aber weder einen geladenen Capture-Kernel noch eine erfolgreiche Sicherung.

cat /proc/cmdline

Unter RHEL 9 kannst du zusätzlich den Status mit dem folgenden Befehl in der Shell abfragen. Auf anderen Distributionen verwendest du den dort dokumentierten Prüfweg. Eine positive Statusmeldung ist ein wichtiger Hinweis auf die Bereitschaft, ersetzt aber keinen kontrollierten Test des gesamten Sicherungswegs.

kdumpctl status

Kontrolliere außerdem, ob das vorgesehene Ziel und die dafür nötigen Treiber im Capture-System verfügbar sind. Halte die gewählten Einstellungen und den Prüfzeitpunkt fest, damit du sie nach Kernel- oder Infrastrukturänderungen erneut beurteilen kannst. Konkrete Einstellungen solltest du vor dem Einsatz für die tatsächlich verwendete Zielplattform überprüfen.

Sicherungsziel und Dumpumfang wählen

Das Sicherungsziel muss während der Erfassung erreichbar sein und ausreichend freien Platz bieten. Ein lokales Ziel vermeidet die Abhängigkeit von einer Netzwerkverbindung, benötigt aber nutzbaren Speicher auf dem Server. Plane auch ein, dass mehrere aufbewahrte Dumps und begleitende Diagnosedateien Platz beanspruchen können.

RHEL 9 dokumentiert neben lokalen Zielen auch Netzwerkziele über NFS oder SSH. Damit lässt sich die Datei getrennt vom betroffenen Server ablegen; dafür müssen Netzwerk, Gegenstelle und die benötigten Komponenten im Capture-System funktionieren. Prüfe die jeweiligen Einschränkungen der konkreten RHEL-Konfiguration, statt die Erreichbarkeit im normalen Betrieb mit der im Capture-System gleichzusetzen.

Mit makedumpfile lässt sich das Abbild komprimieren und nach ausgewählten Speicherbereichen filtern. Filterung kann Speicherplatz und Übertragungsvolumen sparen, entfernt aber Seiten, die für eine spätere Fragestellung fehlen können. Richte den Dumpumfang deshalb an der erwarteten Diagnose aus und dokumentiere die verwendeten Filter; die kleinste Datei ist nicht automatisch die nützlichste.

Ein vmcore kann vertrauliche Inhalte aus dem Arbeitsspeicher enthalten. Begrenze daher den Zugriff, schütze die Übertragung und lege fest, wie lange die Dateien aufbewahrt und wann sie gelöscht werden. Vor einer Weitergabe an einen Supportdienst klärst du die erforderliche Freigabe; das gilt auch für getrennt gespeicherte Kopien.

Einen vorhandenen vmcore mit crash öffnen

Für die nachträgliche Analyse brauchst du den vorhandenen vmcore, ein zum abgestürzten Kernel-Build und zur Architektur passendes vmlinux mit Debuginformationen sowie eine mit Kernel und Dumpformat kompatible Version von crash. Der nach einem Neustart laufende Kernel kann ein anderer sein; seine Versionsanzeige allein identifiziert den abgestürzten Build daher nicht zuverlässig.

Der folgende schematische Aufruf gehört in die normale Shell auf dem Analysesystem. Ersetze beide Pfade durch die tatsächlich vorhandenen Dateien. Der Befehl öffnet ein vorhandenes Abbild zur Analyse; er erzeugt weder einen Dump noch richtet er kdump ein.

crash /pfad/zum/passenden/vmlinux /pfad/zum/vmcore

Nach erfolgreichem Start arbeitest du am crash-Prompt, nicht mehr in der normalen Shell. Dort zeigt log die verfügbaren Kernelmeldungen. Suche zunächst nach der Panic-Meldung und ihrem zeitlichen Umfeld; Meldungen können einen Ansatzpunkt liefern, beschreiben aber nicht zwangsläufig die vollständige Ursache.

Mit bt untersuchst du den Stack des aktuellen Analysekontexts; bt -a zeigt die Stacks der aktiven Tasks auf den CPUs. Vergleiche die Aufrufketten mit den Meldungen, statt einen einzelnen Frame als Schuldnachweis zu behandeln. Je nach Zustand und Umfang des Dumps können Informationen fehlen.

Im selben Prompt hilft ps bei der Übersicht über Tasks; kmem -i liefert allgemeine Speicherinformationen. Diese Momentaufnahme allein beweist weder ein Speicherleck noch dessen Verursacher. Wenn ein beteiligtes Modul genauer untersucht werden soll, können passende Moduldateien und Debuginformationen zusätzlich nötig sein.

Stacks und Speicherhinweise einordnen

Tritt eine Panic nach einer Treiberänderung auf, halte zunächst den Zeitpunkt, den abgestürzten Kernel-Build und die beteiligten Module fest. Vergleiche diese Angaben mit dem Änderungsprotokoll: Wurde nur der Treiber aktualisiert oder zugleich ein neuer Kernel installiert? So grenzt du ein, welche Änderungen für die Untersuchung relevant sind.

Lies anschließend mit log die verfügbaren Kernelmeldungen und untersuche mit bt den Stack des aktuellen Analysekontexts. bt -a ergänzt die Sicht auf aktive Tasks der CPUs. Notiere neben dem Panic-Text auch Meldungen, die der Panic vorausgingen; sie können den Kontext eines später sichtbaren Fehlers liefern.

Ein Treiberframe im Stack ist dabei ein Ansatzpunkt, aber kein Schuldnachweis. Beispielsweise kann eine frühere Speicherbeschädigung erst in einer Treiberfunktion auffallen. Prüfe deshalb, ob Meldungen, beteiligte Module und der Ablauf zusammenpassen, bevor du eine Änderung als Ursache festhältst.

Bei einem Speicherverdacht liefert kmem -i eine Übersicht über Speicherinformationen, soweit der Dump und das Werkzeug sie bereitstellen. Betrachte diese Werte zusammen mit den Kernelmeldungen. Ein einzelner Wert belegt weder ein Speicherleck noch dessen Verursacher; zudem können durch Filterung benötigte Speicherseiten fehlen.

Für die Frage, ob sich ein Verbrauch über die Zeit aufbaut, benötigst du ergänzende Zeitreihen. Bei einer gesonderten Untersuchung von CPU-Last kann CPU-Profiling mit dem Linux Perf Tool helfen. Solche Messungen ergänzen den Crash-Dump, ersetzen aber nicht den darin festgehaltenen Zustand zum Absturzzeitpunkt.

Wenn kein verwertbarer vmcore vorliegt

Nach einem Hänger und anschließendem Neustart ist zuerst zu klären, ob überhaupt eine Panic stattgefunden hat und ob ein vmcore gesichert wurde. Ein Neustart allein belegt beides nicht. Suche nach zeitlich passenden Meldungen und dem konfigurierten Ablageort, bevor du aus dem Fehlen einer Datei auf einen bestimmten Fehler schließt.

Untersuche die Erfassungskette getrennt: War für den betroffenen Boot ein Capture-Kernel geladen, und war das Ereignis geeignet, kdump auszulösen? Nicht jeder Oops führt zu einer Panic. Ein vollständiger Stromverlust oder ein schwerer Hardwarefehler kann außerdem verhindern, dass der Capture-Kernel startet oder Daten schreibt.

Prüfe danach das Sicherungsziel: War es erreichbar, stand genügend Platz zur Verfügung und enthielt das Capture-System die benötigten Treiber und Komponenten? Bei einem Netzwerkziel kommen Verbindung und Gegenstelle als Abhängigkeiten hinzu. Unter RHEL kann die Datei kexec-dmesg.log Hinweise auf die Erfassungsphase geben, sofern sie erstellt und gesichert wurde.

Ohne verwertbaren Dump sind frühere Journale oder persistente Konsolen- und Kernelmeldungen wichtige Alternativen. Diese Quellen liefern jedoch kein vollständiges Speicherabbild; der verlorene Zustand lässt sich nachträglich nicht mit kdump rekonstruieren.

Deuten Meldungen oder andere Beobachtungen auf Netzwerkprobleme hin, kann eine ergänzende Analyse der Linux-SoftIRQ-Auslastung bei der Einordnung der Paketverarbeitung helfen. Sie beantwortet eine andere Frage als die Prüfung des Dump-Ziels und beweist für sich weder eine Panic noch die Ursache einer fehlgeschlagenen Sicherung.

Erfassung testen und Ergebnisse absichern

Wähle den Dumpumfang nach der erwarteten Diagnosefrage und den verfügbaren Ressourcen. Kompression und Filterung können Speicherplatz und Übertragungsvolumen sparen; entfernte Speicherseiten stehen für spätere Untersuchungen aber nicht mehr zur Verfügung. Dokumentiere diese Entscheidung, damit bei der Analyse erkennbar bleibt, welche Daten möglicherweise fehlen.

Ein vmcore kann vertrauliche Speicherinhalte enthalten. Regle deshalb Zugriff, geschützte Übertragung und Aufbewahrungsdauer ebenso wie die Ablage passender Debugdateien. Vor einer Weitergabe an einen Supportdienst klärst du die erforderliche Freigabe und den vorgesehenen Umgang mit den Daten.

Prüfe die Vorbereitung erneut, wenn sich Kernel, Treiber, Bootkonfiguration oder Sicherungsinfrastruktur ändern. Dazu gehören der geladene Capture-Kernel und die Erreichbarkeit des gewählten Ziels. Eine positive Statusmeldung ist nützlich, zeigt für sich aber nicht, ob unter den aktuellen Bedingungen tatsächlich ein analysierbarer Dump entsteht.

Warnung: Ein kontrollierter End-to-End-Test löst absichtlich einen Absturz aus und kann Neustarts und Datenverlust verursachen. Führe ihn nur in einer freigegebenen Testumgebung oder einem vorbereiteten Wartungsfenster mit Datensicherung durch. Kläre vorher Zuständigkeiten, Auswirkungen und Wiederanlauf; ein Auslösebefehl ist hierfür bewusst nicht angegeben.

Ein aussagekräftiger End-to-End-Test endet nicht bei der Statusprüfung: Kontrolliere, ob die Datei am vorgesehenen Ziel angekommen ist und sich mit den zum erfassten Build passenden Dateien öffnen lässt. Halte beim Server Debugging anschließend Befunde, fehlende Daten, Unsicherheiten und die nächsten Prüfschritte fest. Trenne dabei beobachtete Hinweise ausdrücklich von noch unbestätigten Ursachen.