Kernel-Panics und Crash Dumps analysieren mit kdump

1. Was ein Kernel-Panic ist und warum Crash Dumps zählen

Ein Kernel-Panic ist der Moment, in dem der Linux-Kernel einen Zustand erreicht, aus dem er sich nicht mehr sicher erholen kann, etwa eine ungültige Speicherreferenz im Kernel-Space oder eine verletzte interne Invariante. Anders als ein abstürzender Userspace-Prozess kann der Kernel diesen Fehler nicht einfach mit einem Prozess-Kill behandeln, weil er selbst die Instanz ist, die für Speicherverwaltung und Scheduling zuständig ist. Die Konsequenz ist ein sofortiger, kontrollierter Stillstand oder Neustart des gesamten Systems, oft ohne jede Vorwarnung für laufende Dienste.

Ohne einen Crash Dump bleibt nach einem Kernel-Panic nur eine Zeile im seriellen Log oder ein Blackscreen, aus dem sich keine Ursache ableiten lässt. Genau hier setzt kdump an: Es fängt den Absturz ab, sichert den kompletten Arbeitsspeicherinhalt in eine Datei namens vmcore und ermöglicht damit eine forensische Analyse im Nachhinein. Für Produktivserver mit Datenbanken, PHP-FPM-Pools oder virtualisierten Workloads ist ein eingerichteter Crash-Dump-Mechanismus der Unterschied zwischen Rätselraten und einer belastbaren Root-Cause-Analyse.

2. kdump verstehen: kexec, Reserve-Speicher und Crash-Kernel

kdump basiert auf zwei Bausteinen, die zusammen einen sauberen Absturz-Workflow ermöglichen. Der erste Baustein ist kexec, ein Kernel-Feature, das einen neuen Kernel direkt aus einem laufenden Kernel heraus startet, ohne den vollständigen Firmware- und Bootloader-Weg über BIOS oder UEFI zu durchlaufen. Der zweite Baustein ist ein reservierter Speicherbereich, der beim Systemstart per Kernel-Parameter abgetrennt wird und für den regulären Betrieb unsichtbar bleibt.

Tritt ein Kernel-Panic ein, bootet kexec sofort einen minimalen Crash-Kernel in diesen reservierten Speicherbereich. Dieser Crash-Kernel hat Zugriff auf den kompletten Speicherinhalt des abgestürzten Systems und schreibt ihn als vmcore-Datei auf die Platte oder ins Netzwerk, bevor der Server regulär neu bootet. Der entscheidende Vorteil gegenüber einem klassischen Reboot über die Firmware: Der Speicherzustand zum exakten Zeitpunkt des Kernel-Panics bleibt vollständig erhalten, inklusive aller Prozess-Stacks, Locks und Kernel-Datenstrukturen.

3. kdump installieren und konfigurieren

Die Einrichtung von kdump erfordert zwei zusammenhängende Schritte: reservierten Speicher per Kernel-Parameter festlegen und den kdump-Dienst konfigurieren. Der Kernel-Parameter crashkernel bestimmt, wie viel RAM für den Crash-Kernel abgezweigt wird, üblicherweise zwischen 128 und 512 Megabyte je nach Serverspeicher und geladenen Modulen. Ohne ausreichend reservierten Speicher kann der Crash-Kernel selbst nicht sauber starten, wodurch der gesamte Mechanismus wirkungslos bleibt.

# Debian/Ubuntu: install kdump tools
sudo apt install linux-crashdump kdump-tools

# RHEL/Rocky family: install kdump
sudo dnf install kexec-tools

# Reserve memory for the crash kernel via GRUB kernel parameter
sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="crashkernel=256M /' \
  /etc/default/grub
sudo update-grub
sudo systemctl reboot

# Verify the crash kernel memory was actually reserved
cat /proc/cmdline | grep crashkernel
grep -i crashk /var/log/dmesg

# Configure the vmcore storage location (Debian/Ubuntu)
sudo sed -i 's|^KDUMP_KERNEL_PARAMS.*|KDUMP_KERNEL_PARAMS=""|' \
  /etc/default/kdump-tools
echo 'path /var/crash' | sudo tee -a /etc/kdump-tools.conf

# Enable and start the kdump service
sudo systemctl enable --now kdump-tools    # Debian/Ubuntu
sudo systemctl enable --now kdump          # RHEL family
sudo kdumpctl status                       # RHEL family status check

Nach der Installation zeigt cat /sys/kernel/kexec_crash_loaded mit dem Wert 1 an, dass ein Crash-Kernel erfolgreich geladen wurde und im Ernstfall bereitsteht. Wird dieser Wert nie auf 1 gesetzt, funktioniert kdump im Notfall nicht, egal wie sorgfältig die restliche Konfiguration aussieht. Dieser Check gehört deshalb in jede Server-Grundausstattung, in der ein Kernel-Panic mit belastbarer Diagnose beantwortet werden soll.

4. Einen Kernel-Panic gezielt auslösen und testen

Eine kdump-Konfiguration, die nie getestet wurde, ist keine funktionierende Absicherung, sondern eine Annahme. Der Linux-Kernel bietet mit SysRq einen eingebauten Mechanismus, um kontrolliert einen Kernel-Panic auszulösen, ohne echte Hardware- oder Softwarefehler abwarten zu müssen. Dieser Test sollte ausschließlich auf einem Staging-System oder außerhalb der Geschäftszeiten erfolgen, da er den Server tatsächlich zum Absturz bringt.

# Enable the SysRq trigger mechanism (root required)
echo 1 | sudo tee /proc/sys/kernel/sysrq

# Deliberately crash the kernel on a test system to validate kdump
echo c | sudo tee /proc/sysrq-trigger

# After reboot, confirm the crash kernel captured a vmcore
ls -lh /var/crash/*/vmcore

# If no vmcore appears, check the kdump service logs for the failure
journalctl -u kdump-tools --no-pager | tail -50   # Debian/Ubuntu
journalctl -u kdump --no-pager | tail -50         # RHEL family

Ein erfolgreicher Test bestätigt zwei Dinge gleichzeitig: dass der reservierte Speicher ausreicht und dass der Crash-Kernel unter realen Bedingungen bootet. Fehlt danach die vmcore-Datei, liegt das Problem meist an zu wenig reserviertem crashkernel-Speicher oder an fehlenden Storage-Treibern im Crash-Kernel, ein häufiges Problem bei ungewöhnlichen RAID- oder NVMe-Konfigurationen.

5. Die vmcore-Datei mit crash analysieren

Die vmcore-Datei allein ist ein reiner Binär-Dump und für sich genommen nicht lesbar. Das crash-Utility kombiniert diesen Dump mit den Debug-Symbolen des exakt passenden Kernels und stellt daraus eine interaktive Analyseumgebung her, die stark an gdb erinnert. Damit lassen sich Kernel-Datenstrukturen, Prozesslisten und Speicherbereiche zum Zeitpunkt des Kernel-Panics direkt inspizieren, statt auf reine Logzeilen angewiesen zu sein.

# Install the crash utility and matching debug symbols
sudo apt install crash linux-image-$(uname -r)-dbgsym   # Debian/Ubuntu
sudo dnf install crash kernel-debuginfo                 # RHEL family

# Open the vmcore with the matching vmlinux debug image
sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) \
           /var/crash/202607301400/vmcore

# Inside the crash shell, common first commands:
crash> sys                 # basic system information at crash time
crash> log                 # kernel ring buffer as captured in the dump
crash> bt                  # backtrace of the crashing CPU/task
crash> ps | head -20       # process list at the moment of the panic

Der Befehl log innerhalb der crash-Sitzung liefert oft den entscheidenden Hinweis, weil er den Kernel-Ringpuffer exakt so zeigt, wie er zum Absturzzeitpunkt aussah, inklusive der letzten Meldung vor dem Kernel-Panic. In Kombination mit bt für den Backtrace lässt sich meist schon nach wenigen Minuten eingrenzen, ob ein Treiber, ein Dateisystem oder ein Hardwarefehler die Ursache war.

6. Backtrace und Prozesszustand zum Absturzzeitpunkt

Der Backtrace zeigt die Aufrufkette der Kernel-Funktionen, die unmittelbar vor dem Kernel-Panic aktiv waren, von der auslösenden Funktion bis zurück zum Systemaufruf, der sie ursprünglich angestoßen hat. Taucht in dieser Kette ein Treibername auf, etwa ein Netzwerk- oder Storage-Modul, ist das ein starker Hinweis auf eine fehlerhafte Drittanbieter-Komponente statt eines generischen Kernel-Bugs.

Zusätzlich zum Backtrace liefert crash Befehle wie foreach bt, um Backtraces aller laufenden Prozesse gleichzeitig zu erzeugen, und files, um offene Dateideskriptoren eines bestimmten Prozesses zum Absturzzeitpunkt zu sehen. Bei einem Kernel-Panic, der im Zusammenhang mit hoher Systemlast auftrat, zeigt diese Kombination häufig, welcher Prozess gerade wie viel Speicher oder wie viele Dateideskriptoren belegt hat, bevor der Kernel aufgab.

7. Automatisierte Auswertung und Alarmierung

In produktiven Umgebungen soll ein Kernel-Panic nicht erst auffallen, wenn ein Kunde sich meldet. Ein einfaches Skript, das beim Systemstart prüft, ob eine neue vmcore-Datei existiert, kann automatisch eine Benachrichtigung auslösen und die wichtigsten Metadaten des Crashs extrahieren, noch bevor jemand manuell in die crash-Shell einsteigt.

#!/usr/bin/env bash
# check-new-crash.sh — run via a systemd unit at boot
set -euo pipefail

CRASH_DIR="/var/crash"
STATE_FILE="/var/lib/kdump-alert/last-seen"
mkdir -p "$(dirname "$STATE_FILE")"

latest=$(find "$CRASH_DIR" -maxdepth 1 -type d -name '2*' | sort | tail -1)
[[ -z "$latest" ]] && exit 0

last_seen=$(cat "$STATE_FILE" 2>/dev/null || echo "")
if [[ "$latest" != "$last_seen" ]]; then
  summary=$(crash -s "$latest/vmcore" 2>/dev/null <<< "sys; bt" || true)
  echo "New kernel panic detected: $latest" | \
    mail -s "[ALERT] Kernel panic on $(hostname)" ops@example.com
  echo "$summary" >> "$latest/summary.txt"
  echo "$latest" > "$STATE_FILE"
fi

Diese Art der Automatisierung stellt sicher, dass jeder Kernel-Panic dokumentiert und gemeldet wird, unabhängig davon, ob ein Administrator gerade wach ist oder nicht. In Kombination mit einem Monitoring-System lässt sich die Prüfung auch als eigener Check einbinden, der bei jedem neuen Crash-Verzeichnis einen Alarm mit erhöhter Priorität auslöst.

8. Typische Ursachen für Kernel-Panics in Produktion

In der Praxis lassen sich die meisten Kernel-Panics auf wenige wiederkehrende Ursachen zurückführen. Fehlerhafte oder inkompatible Kernel-Module, oft nach einem Kernel-Versionsupgrade ohne vorherige Kompatibilitätsprüfung, stehen an erster Stelle. Auch Hardwaredefekte im Arbeitsspeicher zeigen sich häufig zuerst als sporadischer Kernel-Panic, bevor sie durch andere Symptome auffallen.

# Search past crash summaries for the responsible module or function
grep -A5 '^PID:' /var/crash/*/summary.txt

# Cross-check crash timestamps against recent module or driver changes
for d in /var/crash/*/; do
  echo "=== $d ==="
  crash -s "$d/vmcore" <<< "sys" 2>/dev/null | grep -E 'PANIC|DATE'
done

# Rule out memory errors as a root cause on suspicious hardware
sudo apt install memtester
sudo memtester 1024 1     # test 1 GB of RAM for one pass, offline test preferred

Ein weiterer häufiger Auslöser sind Out-of-Memory-Situationen in Kombination mit fehlerhaftem Swap- oder Cgroup-Setup, bei denen der Kernel selbst in einen inkonsistenten Zustand gerät, statt dass nur der OOM-Killer einen einzelnen Prozess beendet. Auch Firmware-Bugs auf Storage-Controllern und veraltete Netzwerktreiber tauchen in Backtraces von Kernel-Panics überdurchschnittlich oft auf, besonders auf älteren Serverplattformen ohne aktuelle Firmware-Updates.

9. kdump im Vergleich zu anderen Diagnosemethoden

kdump ist nicht die einzige Methode, um Systemabstürze zu untersuchen, aber die einzige, die den vollständigen Speicherzustand zum Zeitpunkt des Kernel-Panics sichert. Andere Werkzeuge liefern ergänzende, aber weniger vollständige Informationen.

In der Praxis ergänzen sich diese Methoden. Ein Kernel-Panic wird zuerst über dmesg oder die serielle Konsole bemerkt, dann liefert kdump die vollständige forensische Grundlage, und Hardware-Logs schließen am Ende aus oder bestätigen einen physischen Defekt als Ursache. Wer nur eine dieser Quellen nutzt, riskiert eine unvollständige oder falsche Diagnose.

10. Zusammenfassung

Ein Kernel-Panic ohne Crash Dump bleibt ein ungelöstes Rätsel, das jederzeit erneut auftreten kann. kdump löst dieses Problem, indem es beim Absturz sofort über kexec einen minimalen Crash-Kernel startet, den vollständigen Speicherinhalt als vmcore sichert und damit eine echte forensische Analyse ermöglicht. Das crash-Utility macht diesen Dump lesbar und liefert Backtrace, Prozessliste und Kernel-Log genau zum Zeitpunkt des Absturzes.

Wichtig ist, kdump nicht erst nach dem ersten Kernel-Panic einzurichten, sondern präventiv auf jedem Produktivserver, inklusive eines echten Tests über SysRq auf einem Staging-System. Automatisierte Alarmierung bei neuen vmcore-Dateien und ein systematischer Blick auf wiederkehrende Ursachen wie fehlerhafte Treiber oder Hardwaredefekte verwandeln einen einmaligen Vorfall in einen wiederholbaren, gut dokumentierten Diagnoseprozess.

11. FAQ: Kernel-Panics und Crash Dumps