Wenn ein Entwicklungs-Kernel (z.B. FreeBSD-CURRENT) wie zum Beispiel ein Kernel unter Extrembedingungen (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. In HEAD ist die Standardeinstellung für
dumpdev AUTO und änderte sich in
den RELENG_*-Zweigen (mit Ausnahme von RELENG_7, bei dem AUTO
beibehalten wurde) auf NO. In FreeBSD 9.0-RELEASE und späteren
Versionen fragt bsdinstall, ob Speicherauszüge für das
Zielsystem während des Installationsvorgangs aktiviert werden sollen.
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>.