Wer unsicher ist, kann sich durch einen Blick in
»/proc/iomem
«
davon überzeugen, dass der geschützte Speicherbereich markiert ist (siehe
Listing 1
). Ist alles korrekt verlaufen, kann das Start-Skript von
»kdump
«
den Crash-Kernel in den Speicher laden. Typischerweise bindet der Admin dies in den regulären Boot-Prozess ein, für die ersten Gehversuche reicht aber auch eine manuelle Aktivierung.
Listing 1
Vorbereitungen für den Kernel-Dump
An dieser Stelle gilt es, das konfigurierte Setup zu überprüfen, sprich künstlich einen Kernel-Crash auszulösen, der dann automatisch das Schreiben des Dumps starten sollte. Dafür schaltet man über
»echo 1 > /proc/sys/kernel/sysrq
«
zunächst die sogenannten Magic Sysrequest Keys ein. Im Normallfall ist das schon erledigt, wenn der Admin die Distributionswerkzeuge zum Einrichten des Kernel-Dumps verwendet hat.
Ein beherztes
»echo c > /proc/sysrq-trigger
«
löst jetzt einen Kernel-Panic aus. Wenn alles funktioniert, startet das System dann den Crash-Kernel, der wiederum
»kdump
«
beziehungsweise
»makedumpfile
«
auslöst (
Abbildung 2
).
Jeden Dump legt das System in einem mit dem Erzeugungsdatum versehenen Verzeichnis ab. Stürzt das System mehrfach ab, werden bereits gespeicherte Informationen so nicht überschrieben. Noch eine Nebenbemerkung für die Suse-Anhänger: Sie können den Kernel-Panic auch über das Laden des Modules
»crasher.ko
«
auslösen. Dies stammt übrigens aus der Feder von Btrfs-Entwickler Chris Mason, als er noch bei Suse arbeitete
[8]
.
Waren die ersten Dump-Versuche erfolgreich, kann es an das Tuning gehen. Da wäre zunächst die Speicher-Reservierung für den Crash-Kernel. Die allgemeine Anweisung lautet
»crashkernel=Bereich1:Grösse1[,Bereich2:Grösse2,...][@Adresse]
«
. Im konkreten Fall von
»crashkernel=512M-2G:64M,2G-:128M
«
heißt das: Für einen RAM-Ausbau von 512 MByte bis 2 Gyte reserviert das System 64 MByte und 128 MByte bei mehr als 2 GByte Hauptspeicher. Das vereinfacht die Konfiguration des Bootloaders für eine heterogene Hardware-Umgebung. Unabhängig vom Hauptspeicher bleibt der
»crashkernel
«
-Eintrag immer derselbe. Bei Suse macht Yast das automatisch. Die Angaben von Größe und Bereich können laut Kernel-Dokumentation auch in KByte erfolgen, allerdings ist dies für die Praxis nicht relevant.
In der Standard-Konfiguration speichert das System den Kernel-Dump der lokalen Platte. Bei Systemen mit üppigem Hauptspeicher kann es da schnell zu Problemen kommen. Glücklicherweise erlaubt das Kexec/Kdump-Gespann auch das Speichern über das Netzwerk. Der Admin hat dabei die Wahl zwischen NFS und SSH/SCP. Tabelle 1 listet die verfügbaren Optionen auf.
Tabelle 1
Ablagemöglichkeiten für den Kernel-Dump
Variante |
Beschreibung |
---|---|
raw /dev/sdc1 |
Schreibt den Dump mit
» |
ext3 /dev/sdc1 |
Hängt
» |
ext4 LABEL=/dump |
Hängt das Dateisystem mit diesem Label ein und legt den Dump dort ab. |
net mynfs.server.com:/export/dump |
Integriert das entsprechende NFS-Share des Servers und schreibt den Dump dorthin. |
Speichert den Dump über SCP als entsprechenden Nutzer auf dem Server. |
Das Schreiben über SSH/SCP setzt eine nicht-interaktive Authentisierung beispielsweise über Schlüssel voraus. Es empfiehlt sich daher, einen separaten und recht eingeschränkten Ziel-Benutzer zu konfigurieren.