From MsgServerDocWiki

This page pertains to Solaris. For information about Linux, see http://kbase.redhat.com/faq/docs/DOC-2699

[edit] Getting core dumps

On Solaris, to cause core files to be uniquely named and stored in a consistent place, as root, use a coreadm command like:

 % mkdir -p /var/cores
 % coreadm -g /var/cores/%f.%n.%p.%t.core \
 -e global \
 -e global-setid \
 -e log \
 -d process \
 -d proc-setid

Make sure /var/cores is on file system with sufficient space and check the directory occasionally.

The -g switch specifies the global core file name pattern. Unless a per-process pattern or setting overrides it, core files will be stored in the specified directory with a name like:

   <program>.<node>.<pid>.<time>.core

eg: mytest.myhost.1234.1102010309.core

The "-e" switch specifies options to enable. The above command will enable:

• the use of the global (ie system-wide) core file name pattern (and thereby location)
• setuid programs will also dump core as per the same pattern
• any attempt to dump core (successful or not) will generate a syslog message

The "-d" switch specifies options to disable. The above command will disable:

• core dumps per the per-process core file pattern
• per-process core dumps of setuid programs.

The result will be that all core dumps will be stored in the central location with names identifying what dumped core and when.

These changes will only effect processes started after the coreadm command is run. Use "coreadm -u" after the above to apply the settings to all existing processes.

Also note that the per-process limit for core file size can prevent a process from dumping core. Any such failed attempt will be logged to /var/adm/messages as per the syslog configuration and the "-e log" specified above. You can use "plimit <pid>" to see the current limits of a process. If it shows coredump size is 0, then that process will not be able to dump core. If this is the case, you should change the system-wide login script which is setting it to 0, or change the startup script for that process, to allow coredump size to be unlimited.

[edit] Be careful of your disk space

By default coreadm is not set and core dumps will try to go into the current working directory of the process and will be called "core". Thus any core dump may overwrite a previous dump, possibly of a different process. And the core files may not be in a location you would think to look. With the above setting, they will be uniquely named and in a consistent location. That also means they can build up. So be careful to put them on a file system with sufficient space and be careful to purge, or at least monitor, this directory.

[edit] What to do with a core dump

The first thing support will need is just the output of running pstack on that core file. This may provide sufficient information to identify a known bug without having to analyze the core.

If support needs the core file, they will also need the libraries associated with the process. The pkg_app script gathers that information, but it does not necessarily include the core file. So get pkg_app from the Big Admin script site, run that, and send both the pkg_app output file and the core file.

You only need to run pkg_app on each type of core file. For example, if you get several core files from mshttpd processes, run pstack on each of them and send that to support. If support needs the cores, run pkg_app on one of them and send that pkg_app output and all the core files. If you also have tcp_smtp_server cores, then those cores will need pkg_app run again on one of those cores. And if you install patches or anything that would change libraries, then run pkg_app again for any new core files.