Wenn ein Entwicklungs-Kernel (z.B. FreeBSD-CURRENT) wie zum Beispiel ein Kernel unter Extrembedinungen (z.B. sehr hohe Belastungsraten (Load), eine äußerst hohe Anzahl an gleichzeitigen Benutzern, Hunderte jail(8)s usw.) eingesetzt oder eine neue Funktion oder ein neuer Gerätetreiber in FreeBSD-STABLE verwendet wird (z.B. PAE), tritt manchmal eine Kernel-Panic ein. In einem solchen Fall zeigt dieses Kapitel, wie dem Absturz nützliche Informationen entnommen werden können.
Bei Kernel-Panics ist ein Neustart unvermeidlich. Nachdem ein System neu gestartet wurde, ist der Inhalt des physikalischen Speichers (RAM), genauso wie jedes Bit, das sich vor der Panic auf dem Swap-Gerät befand, verloren. Um die Bits im physikalischen Speicher zu erhalten, zieht der Kernel Nutzen aus dem Swap-Gerät als vorübergehenden Ablageort, wo die Bits, welche sich im RAM befinden, auch nach einem Neustart nach einem Absturz verfügbar sind. Durch diese Vorgehensweise kann ein Kernel-Abbild, wenn FreeBSD nach einem Absturz startet, abgezogen und mit der Fehlersuche begonnen werden.
Anmerkung: Ein Swap-Gerät, das als Ausgabegerät (Dump-Device) konfiguriert wurde, verhält sich immer noch wie ein Swap-Gerät. Die Ausgabe auf Nicht-Swap-Geräte (wie zum Beispiel Bänder oder CDRWs) wird zur Zeit nicht unterstützt. Ein “Swap-Gerät” ist gleichbedeutend mit einer “Swap-Partition”.
Es stehen verschiedene Arten von Speicherabzügen zur Verfügung: komplette Speicherabzüge (full memory dumps), welche den gesamten Inhalt des physischen Speichers beinhalten, Miniauszüge (minidumps), die nur die gerade verwendeten Speicherseiten des Kernels enthalten (FreeBSD 6.2 und höhere Versionen) und Textauszüge (textdumps), welche geskriptete oder Debugger-Ausgaben enthalten (FreeBSD 7.1 und höher). Miniauszüge sind der Standardtyp der Abzüge seit FreeBSD 7.0 und fangen in den meisten Fällen alle nötigen Informationen ein, die in einem kompletten Kernel-Speicherabzug enthalten sind, da die meisten Probleme nur durch den Zustand des Kernels isoliert werden können.
Bevor der Kernel den Inhalt seines physikalischen Speichers auf einem
Ausgabegerät ablegt, muss ein solches konfiguriert werden. Ein Ausgabegerät
wird durch Benutzen des dumpon(8)-Befehls
festgelegt, um dem Kernel mitzuteilen, wohin die Speicherauszüge bei einem
Kernel-Absturz gesichert werden sollen. Das dumpon(8)-Programm
muss aufgerufen werden, nachdem die Swap-Partition mit swapon(8) konfiguriert
wurde. Dies wird normalerweise durch Setzen der dumpdev-Variable in rc.conf(5) auf den
Pfad des Swap-Geräts (der empfohlene Weg, um einen Kernel-Speicherauszug zu
entnehmen) bewerkstelligt, oder über AUTO, um die erste
konfigurierte Swap-Partition zu verwenden. AUTO ist seit
FreeBSD 6.0 die Standardeinstellung.
Tipp: Vergleichen Sie /etc/fstab oder swapinfo(8) für eine Liste der Swap-Geräte.
Wichtig: Stellen Sie sicher, dass das in rc.conf(5) festgelegte
dumpdirvor einem Kernel-Absturz vorhanden ist.# mkdir /var/crash # chmod 700 /var/crashDenken Sie auch daran, dass der Inhalt von /var/crash heikel ist und sehr wahrscheinlich vertrauliche Informationen wie Passwörter enthält.
Sobald ein Speicherauszug auf ein Ausgabegerät geschrieben wurde, muss er
entnommen werden, bevor das Swap-Gerät eingehängt wird. Um einen Speicherauszug
aus einem Ausgabegerät zu entnehmen, benutzen Sie das savecore(8)-Programm.
Falls dumpdev in rc.conf(5) gesetzt
wurde, wird savecore(8)
automatisch beim ersten Start in den Multiuser-Modus nach dem Absturz und vor dem
Einhängen des Swap-Geräts aufgerufen. Der Speicherort des entnommenen Kernels
ist im rc.conf(5)-Wert dumpdir, standardmäßig /var/crash, festgelegt und der Dateiname wird vmcore.0 sein.
In dem Fall, dass bereits eine Datei mit dem Namen vmcore.0
in /var/crash (oder auf was auch immer dumpdir gesetzt ist) vorhanden ist, erhöht der Kernel die
angehängte Zahl bei jedem Absturz um eins und verhindert damit, dass ein vorhandener
vmcore (z.B. vmcore.1)
überschrieben wird. Während der Fehlersuche, möchten Sie höchst
wahrscheinlich den vmcore mit der höchsten Version in /var/crash benutzen, wenn Sie den passenden vmcore suchen.
Tipp: Falls Sie einen neuen Kernel testen, aber einen anderen starten müssen, um Ihr System wieder in Gang zu bringen, starten Sie es nur in den Singleuser-Modus, indem Sie das
-s-Flag an der Boot-Eingabeaufforderung benutzen, und nehmen dann folgende Schritte vor:# fsck -p # mount -a -t ufs # make sure /var/crash is writable # savecore /var/crash /dev/ad0s1b # exit # exit to multi-userDies weist savecore(8) an, einen Kernel-Speicherauszug aus /dev/ad0s1b zu entnehmen und den Inhalt in /var/crash abzulegen. Vergessen Sie nicht sicherzustellen, dass das Zielverzeichnis /var/crash genug freien Speicherplatz für den Speicherauszug zur Verfügung hat. Vergessen Sie auch nicht, den korrekten Pfad des Swap-Geräts anzugeben, da es sehr wahrscheinlich anders als /dev/ad0s1b lautet!
| Zurück | Zum Anfang | Weiter |
| Einen Kernel auf die “neue” Art und Weise bauen | Nach oben | Fehlersuche in einem Speicherauszug nach einem Kernel-Absturz mit kgdb |
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.