Ein Abbild des Systemspeichers, das nach einem Kernel-Absturz oder -Hängen erfasst wird, wird als Crash-Dump bezeichnet. Die Analyse eines Crash-Dumps kann wertvolle Hinweise für Post-Mortem-Analysen von Kernel-Problemen geben. Das Erhalten eines Dumps nach einem Kernel-Absturz ist jedoch von Natur aus unzuverlässig, da sich der Speichertreiber, der für die Protokollierung von Daten auf dem Dump-Gerät verantwortlich ist, möglicherweise in einem undefinierten Zustand befindet.
kdump-Konfigurationseinstellungen werden in der Konfigurationsdatei /etc/kdump.conf gespeichert. Unten ist eine Beispieldatei /etc/kdump.conf von einem CentOS/RHEL 8-Rechner.
# cat /etc/kdump.conf# Diese Datei enthält eine Reihe von Befehlen, die (der Reihe nach) im kdump
# Kernel auszuführen sind, nachdem ein Kernel-Absturz im Crash-Kernel (1. Kernel) aufgetreten ist.
#
# Direktiven in dieser Datei gelten nur für kdump initramfs und haben
# keine Auswirkung, sobald das Root-Dateisystem gemountet ist und die normalen Init-Skripte
# verarbeitet werden.
#
# Derzeit kann nur ein Dump-Ziel und -Pfad angegeben werden. Wenn das Dumping zum
# konfigurierten Ziel fehlschlägt, wird die Fehleraktion ausgeführt, die über die
# Direktive „failure_action“ konfiguriert werden kann.
#
# Unterstützte Optionen:
#
# raw
# – Wird /proc/vmcore in
# Dauerhafte Gerätenamen für Partitionsgeräte verwenden,
# wie z /dev/vg/
#
# nfs
# – Mountet nfs auf
#
#
# ssh
# – Speichert /proc/vmcore unter
# unterstützt DNS.
# HINWEIS:Stellen Sie sicher, dass der Benutzer Schreibrechte auf dem Server hat.
#
# sshkey
# – Verwendet den sshkey, um einen ssh-Dump durchzuführen.
# Geben Sie den Pfad des ssh-Schlüssels an, der beim Dump
# über ssh verwendet werden soll. Der Standardwert ist /root/.ssh/kdump_id_rsa.
#
#
# – Mountet -t
# /proc/vmcore nach
# HINWEIS:
# Es ist Es wird empfohlen, dauerhafte Gerätenamen zu verwenden
# wie /dev/vg/
# Andernfalls wird empfohlen, label oder uuid zu verwenden.
#
# Pfad
# – „Pfad“ stellt den Dateisystempfad dar, in dem vmcore
# gespeichert wird. Wenn ein Speicherauszugsziel in
# kdump.conf angegeben ist, dann ist „Pfad“ relativ zum angegebenen
# Speicherauszugsziel.
#
# Interpretation von „Pfad“ ändert sich a Bit, wenn der Benutzer
# kein Dump-Ziel explizit in kdump.conf angegeben hat. In diesem
# Fall steht „Pfad“ für den absoluten Pfad vom Stammverzeichnis. Das
# Dump-Ziel und der angepasste Pfad werden automatisch
# erreicht, je nachdem, was im aktuellen System gemountet ist.
#
# Ignoriert für Raw-Device-Dumps. Wenn nicht gesetzt, wird der Standard
# „/var/crash“ verwendet.
#
# core_collector
# – Damit können Sie den Befehl angeben kopieren
# den vmcore. Der Standardwert ist makedumpfile, was auf
# einigen Architekturen die vmcore-Größe drastisch reduzieren kann.
# Eine Liste der Optionen finden Sie unter /sbin/makedumpfile –help.
# Beachten Sie, dass -i und - g-Optionen werden hier nicht benötigt,
# da die initrd automatisch mit einer
# für den laufenden Kernel geeigneten Konfigurationsdatei gefüllt wird.
# Der standardmäßige core_collector für raw/ssh-Dump ist:
# „makedumpfile -F -l –message-level 7 -d 31“.
# Der standardmäßige core_collector für andere Ziele ist:
# „makedumpfile -l –message-level 7 -d 31 ”.
#
# „makedumpfile -F“ erstellt einen abgeflachten virtuellen Kern.
# Sie müssen „makedumpfile -R“ verwenden, um die Dump-Daten
# in einen normalen umzuordnen Dumpfile lesbar mit Analysetools. Zum Beispiel:
# „makedumpfile -R vmcore
# Details zum core_collector-Format finden Sie in
# kexec-kdump-howto.txt oder kdump.conf manpage.
#
# kdump_post
# – Mit dieser Anweisung können Sie eine ausführbare Binärdatei
# oder ein Skript ausführen, nachdem der vmcore-Dump-Prozess beendet wurde.
# Der Exit-Status des aktuellen Dump-Prozesses wird an
# die ausführbare Binärdatei oder das Skript als erstes Argument.
# Alle Dateien unter /etc/kdump/post.d werden kollektiv sortiert
# und in lexikalischer Reihenfolge vor der Binärdatei oder dem Skript ausgeführt
# Der angegebene kdump_post-Parameter wird ausgeführt.
#
# kdump_pre
# – Funktioniert wie die „kdump_post“-Direktive, aber anstatt
# nach dem Dump-Prozess zu laufen, wird es unmittelbar davor ausgeführt.
# Der Exit-Status dieser Binärdatei wird wie folgt interpretiert:
# 0 – wie gewohnt mit dem Dump-Prozess fortfahren
# nicht 0 – die letzte Aktion ausführen (reboot/poweroff/halt)
# Alle Dateien unter /etc/kdump/pre.d sind zusammengefasst sortiert und
# in lexikalischer Reihenfolge ausgeführt, nachdem die Binärdatei oder das Skript angegeben wurde
# Der Parameter kdump_pre wird ausgeführt.
# Auch wenn die Binärdatei oder das Skript im Verzeichnis /etc/kdump/pre.d
# gibt einen Exit-Status ungleich 0 zurück, die Verarbeitung wird fortgesetzt.
#
# extra_bins
# – Mit dieser Direktive können Sie zusätzliche Binärdateien oder
# Shell-Skripte angeben, die in die kdump initrd aufgenommen werden sollen.
# Im Allgemeinen sind sie in Verbindung mit einem kdump_post nützlich
# oder kdump_pre-Binärdatei oder -Skript, das von diesen extra_bins abhängt.
#
# extra_modules
# – Diese Direktive erlaubt Ihnen, zusätzliche Kernelmodule anzugeben
# die Sie in die kdump initrd laden möchten.
# Es können mehrere Module aufgelistet werden, getrennt durch Leerzeichen, und alle
# abhängigen Module werden automatisch eingeschlossen.
#
# Fehler_Aktion
# – Aktion, die ausgeführt werden soll, falls das Dumping fehlschlägt.
# reboot:System neu starten.
# halt:System anhalten.
# poweroff:System herunterfahren.
# Shell:Wechseln Sie zu einer Bash-Shell.
# Beim Beenden der Shell wird das System standardmäßig neu gestartet,
# oder führen Sie „final_action“ aus.
# dump_to_rootfs:Sichern Sie vmcore in rootfs von initramfs-Kontext und
# standardmäßig neu starten oder „final_action“ ausführen.
# Nützlich, wenn ein Nicht-Root-Dump-Ziel angegeben ist.
# Die Standardoption ist „reboot“.
#
# default
# – Wie die „failure_action“-Direktive oben, aber diese Direktive
# ist veraltet und wird in Zukunft entfernt.
#
# final_action
# – Aktion, die ausgeführt werden soll, falls das Dumping erfolgreich ist. Wird auch
# ausgeführt, wenn die Fehleraktion „shell“ oder „dump_to_rootfs“ beendet wird.
# Jede Aktion entspricht der obigen „failure_action“-Anweisung.
# Der Standardwert ist „reboot“.
#
# force_rebuild <0 | 1>
# – Standardmäßig wird kdump initrd nur bei Bedarf neu erstellt.
# Geben Sie 1 an, um die Neuerstellung von kdump initrd jedes Mal zu erzwingen, wenn der kdump
# Dienst gestartet wird.
#
# force_no_rebuild <0 | 1>
# – Standardmäßig wird kdump initrd bei Bedarf neu erstellt.
# Geben Sie 1 an, um die Neuerstellung von kdump initrd zu umgehen.
#
# force_no_rebuild und force_rebuild Optionen sind gegenseitig
# exklusiv und sie sollten nicht gleichzeitig auf 1 gesetzt werden.
#
# override_resettable <0 | 1>
# – Normalerweise kann ein nicht rücksetzbares Blockgerät kein Dump-Ziel sein.
# Angabe von 1, wenn Sie einen Dump durchführen möchten, obwohl das Blockziel
# nicht rücksetzbar ist
# Standardmäßig ist es 0, wodurch kein Dump versucht wird, der fehlschlagen soll.
#
# dracut_args
# – Übergeben Sie zusätzliche dracut-Optionen, wenn Sie kdump initrd neu erstellen.
#
# fence_kdump_args
# – Befehlszeilenargumente für fence_kdump_send (es kann
# alle gültigen Argumente außer Hosts enthalten, an die Benachrichtigungen gesendet werden sollen).
#
# fence_kdump_nodes
# – Liste der Cluster-Knoten außer localhost, durch Leerzeichen getrennt,
# an die fence_kdump-Benachrichtigungen gesendet werden sollen.
# ( diese Option ist zwingend erforderlich, um fence_kdump zu aktivieren).
#
#raw /dev/vg/lv_kdump
#ext4 /dev/vg/lv_kdump
#ext4 LABEL=/boot
#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
#nfs my.server.com:/export/tmp
#nfs [2001:db8::1:2:3:4]:/export/tmp
#ssh [email protected]. com
#ssh user@2001:db8::1:2:3:4
#sshkey /root/.ssh/kdump_id_rsa
path /var/crash
core_collector makedumpfile - l –message-level 7 -d 31
#core_collector scp
#kdump_post /var/crash/scripts/kdump-post.sh
#kdump_pre /var/crash/scripts/kdump-pre .sh
#extra_bins /usr/bin/lftp
#extra_modules gfs2
#failure_action shell
#force_rebuild 1
#force_no_rebuild 1
#dracut_args – auslassen -drivers „cfg80211 snd“ –add-drivers „ext2 ext3“
#fence_kdump_args -p 7410 -f auto -c 0 -i 10
#fence_kdump_nodes node1 node2