diff --git a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml index 64494cd32f..7af0b78178 100644 --- a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml +++ b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml @@ -12,27 +12,28 @@ Obtaining a Kernel Crash Dump - When running a development kernel (eg: &os.current;), a + When running a development kernel (eg: &os.current;), such as a kernel under extreme conditions (eg: very high load averages, tens of thousands of connections, exceedingly high number of concurrent users, hundreds of &man.jail.8;s, etc.), or using a new feature or device driver on &os.stable; (eg: PAE), sometimes a kernel will panic. In the - event that it does, this chapter includes basic instructions for - extracting useful information out of a crash. + event that it does, this chapter will demonstrate how to extract + useful information out of a crash. A system reboot is inevitable once a kernel panics. Once a system is rebooted, the contents of a system's physical memory (RAM) is lost, as well as any bits that are on the swap device before the panic. To preserve the bits in physical memory, the kernel makes use of the swap device as a - place to store the bits that are in physical memory that way - when the system reboots, a kernel image can be extracted and - debugging can take place. + temporary place to store the bits that are in RAM across a + reboot after a crash. In doing this, when &os; boots after a + crash, a kernel image can now be extracted and debugging can + take place. A swap device that has been configured as a dump - device still acts as a swap device. Dumps to non-swap devices, - tapes for example, are not supported at this time. A + device still acts as a swap device. Dumps to non-swap devices + (such as tapes or CDRWs, for example) are not supported at this time. A swap device is synonymous with a swap partition. @@ -42,8 +43,7 @@ reboots, the kernel is smart enough to check to see if a swap device has been configured as a dump device. If there is a valid dump device, the kernel dumps the contents of what is in - physical memory to the swap device (assuming the swap device is - configured as a dump device). + physical memory to the swap device. Configuring the Dump Device @@ -55,13 +55,13 @@ &man.dumpon.8; program must be called after the swap partition has been configured with &man.swapon.8;. This is normally handled by setting the dumpdev variable in - &man.rc.conf.5; to the path of the swap device. + &man.rc.conf.5; to the path of the swap device (the + recommended way to extract a kernel dump). - Alternatively, you can hard-code the dump device via the - dump clause in the config line of - your kernel configuration file. This approach is deprecated and should - be used only if you want a crash dump from a kernel that crashes during - booting. + Alternatively, the dump device can be hard-coded via the + dump clause in the &man.config.5; line of + a kernel configuration file. This approach is deprecated and should + be used only if a kernel is crashing before &man.dumpon.8; can be executed. Check /etc/fstab or &man.swapinfo.8; for a list of swap devices. @@ -70,7 +70,12 @@ specified in &man.rc.conf.5; exists before a kernel crash! - &prompt.root; mkdir /var/crash + &prompt.root; mkdir /var/crash +&prompt.root; chmod 700 /var/crash + + Also, remember that the contents of + /var/crash is sensitive and very likely + contains confidential information such as passwords. @@ -78,15 +83,28 @@ Extracting a Kernel Dump Once a dump has been written to a dump device, the dump - must be extracted before the swap device is mounted, - otherwise the dump will be corrupted. To extract a dump + must be extracted before the swap device is mounted. + To extract a dump from a dump device, use the &man.savecore.8; program. If dumpdev has been set in &man.rc.conf.5;, &man.savecore.8; will be called automatically on the first multi-user boot after the crash and before the swap device is mounted. The location of the extracted core is placed in the &man.rc.conf.5; value dumpdir, by - default /var/crash. + default /var/crash and will be named + vmcore.0. + + In the event that there is already a file called + vmcore.0 in + /var/crash (or whatever + dumpdev is set to), the kernel will + increment the trailing number for every crash to avoid + overwriting an existing vmcore (eg: + vmcore.1). While debugging, it is + highly likely that you will want to use the highest version + vmcore in + /var/crash when searching for the right + vmcore. If you are testing a new kernel but need to boot a different one in @@ -103,14 +121,13 @@ from /dev/ad0s1b and place the contents in /var/crash. Don't forget to make sure the destination directory /var/crash has enough - space for the dump or to specify the correct path to your swap + space for the dump. Also, don't forget to specify the correct path to your swap device as it is likely different than /dev/ad0s1b! - The recommended and certainly easiest way to automate + The recommended, and certainly the easiest way to automate obtaining crash dumps is to use the dumpdev variable in &man.rc.conf.5;. - @@ -123,8 +140,10 @@ the crash dump, locate the debug version of your kernel (normally called kernel.debug) and the path to the source files used to build your kernel (normally - /usr/obj/usr/src/sys/KERNCONF). With those - two pieces of info, let the debugging commence! + /usr/obj/usr/src/sys/KERNCONF, where + KERNCONF is the ident + specified in a kernel &man.config.5;). With those two pieces of + info, let the debugging commence! &prompt.root; cd /usr/obj/usr/src/sys/KERNCONF &prompt.root; gdb -k /boot/kernel/kernel.debug /var/crash/vmcore.0 @@ -277,6 +296,11 @@ + + If your system is crashing regularly and you're running + out of disk space, deleting old vmcore + files in /var/crash could save a + considerable amount of disk space!