/etc/init.d/sysetup in Solaris 2.6 and earlier, or by
dumpadm and /etc/init.d/savecore in Solaris
7 and later). If the system is hung, it may be necessary to force
a panic by using Stop-a and typing sync at the
ok> prompt. (sync forces a write from memory to
swap.)
There are several reasons why savecore may be unable to save a core following a panic. These include:
- The primary swap area may not be big enough to hold the coredump.
Solaris 7 and later versions are more careful about only preserving
"interesting" parts of memory, but coredumps may still be 128 M or
35% of main memory, whichever is larger. In Solaris 7, the main dump
device can be specified with
dumpadm. Solaris 2.6 and earlier use the first swap device specified in the/etc/vfstab. - The dump area may be too large. Although some patches have been released to deal with this problem, dump partitions larger than 2G can cause problems with a core dump.
- The dump area is not on a regular disk. If the swap area is managed by Veritas or Disk Suite, it is possible that this software may not be functional at the time of the dump. A regular disk partition should be specified as the primary dump area.
- The dump area is not local. If the NFS client software is not functional at the time of the software, memory may not be able to dump to the swap area.
- The dump device hardware is having problems. Use hardware diagnostics to check out the hardware in question.
- The storage area for the corefiles is too small. By
default, the storage area is in
/var/crash. Either make sure that there is enough storage space there or change the storage area to a partition with more space. - The storage area hardware has problems. Use hardware diagnostics to check out the hardware in question.
savecoreis not enabled after all.
After you have a corefile, it can be submitted
to Sun for analysis. You can perform some initial analysis yourself, using either
mdb or adb.
No comments:
Post a Comment