Oracle Solaris Modular Debugger Guide

Forcing a Crash Dump

The next step is to make sure crash dumps are properly configured. First, confirm that dumpadm is configured to save kernel crash dumps and that savecore is enabled. See dumpadm(1M) for more information on crash dump parameters.

# dumpadm
              Dump content: kernel pages
               Dump device: /dev/dsk/c0t0d0s1 (swap)
        Savecore directory: /var/crash/testsystem
          Savecore enabled: yes
           Save compressed: on

Next, reboot the system using the -d flag to reboot(1M), which forces the kernel to panic and save a crash dump.

# reboot -d
Sep 28 17:51:18 testsystem reboot: rebooted by root

panic[cpu0]/thread=70aacde0: forced crash dump initiated at user request

401fbb10 genunix:uadmin+55c (1, 1, 0, 6d700000, 5, 0)
  %l0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
         00000000
...

When the system reboots, savecore runs automatically to preserve the crash dump in a file. When finished, a message is printed on the system console:

Sep 17 10:47:23 testsystem savecore: Decompress the crash dump with
Sep 17 10:47:23 testsystem 'savecore -vf /var/crash/testsystem/vmdump.0'

If the message does not appear right away, check to whether savecore(1M) is still running:


$ pgrep savecore
864
$ cd /var/crash/testsystem
$ ls
bounds    vmdump.0

The vmdump.n file is a compressed version of vmcore.n plus unix.n.

If your dump directory contains no dump files , then that partition might be out of space. You can free up space and run savecore(1M) manually as root to subsequently save the dump.

If your dump directory contains multiple crash dumps, the one you just created is the unix.n and vmcore.n pair or vmdump.n file with the most recent modification time.