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.