Sun Gathering Debug Data for Sun Java System Directory Proxy Server 5

1.6 Configuring the Operating System to Generate Core Files

Core files and crash dumps are generated when a process or application terminates abnormally. You can also generate core files and crash dumps to help diagnose why a process does not respond to client application requests.

This section includes the following procedures:

ProcedureTo Configure Solaris OS to Generate Core Files

This procedure shows you how to use the coreadm command to configure the system so that all process core files are placed in a single system directory. This means it is easier to track problems by examining core files in a specific directory whenever a Solaris OS process or daemon terminates abnormally.

Before You Begin

Make sure that the /var file system where the core files are generated has sufficient space. Once you configure Solaris OS to generate core files as shown here, all processes that crash write a core file to the /var/cores directory.

  1. Run the following commands as root.

    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

    In this command:

    -g

    Specifies the global core file name pattern. Unless a per-process pattern or setting overrides it, core files are stored in the specified directory with a name such as program.node.pid.time.core, for example: mytest.myhost.1234.1102010309.core.

    -e

    Specifies options to enable. The preceding command enables:

    • Use of the global (that is, system-wide) core file name pattern (and thereby location)

    • Capability of setuid programs to also dump core as per the same pattern

    • Generation of a syslog message by any attempt to dump core (successful or not)

    -d

    Specifies options to disable. The preceding command disables:

    • Core dumps per the per-process core file pattern

    • Per-process core dumps of setuid programs

    The preceding command stores all core dumps in a central location with names identifying what process dumped core and when. These changes only impact processes started after you run the coreadm command. Use the coreadm -u command after the preceding command to apply the settings to all existing processes.

  2. Display the core configuration.


    # coreadmglobal core file pattern: /var/cores/%f.%n.%p.%t.core
          init core file pattern: core
               global core dumps: enabled
          per-process core dumps: disabled
         global setid core dumps: enabled
    per-process setid core dumps: disabled
        global core dump logging: enabled 

    See the coreadm man page for further information.

  3. Set the file size as large as possible, using the ulimit command.


    # ulimit -c unlimited
    # ulimit -a
           coredump(blocks) unlimited

    See the ulimit(1) man page for details.

  4. Verify that applications can in fact generate core files.


    # cd /var/cores
    # sleep 100000 &
    [1] pid
    # kill -8 pid
    # ls

    You should see a core file for the sleep process you killed.

ProcedureTo Configure Red Hat Linux to Generate Core Files

On Red Hat systems, you can enable core files to be generated on a per user basis.

  1. Open the ~/.bash_profile file for the server user in a text editor.

  2. Search for a line using the ulimit command as follows.

    ulimit -S -c 0 > /dev/null 2>&1
  3. Either comment out the line, or set your own limit for core file size.

ProcedureTo Configure Windows to Generate Crash Dumps

The native debug tool on Windows systems, Dr. Watson, allows you to generate crash dumps.

However, Dr. Watson does not allow generation of crash dumps on a running process. To generate crash dumps from a running process, install the Debugging Tools. The Debugging Tools are freely available from the Windows web site at http://www.microsoft.com/whdc/devtools/debugging/default.mspx.

  1. You can use Dr. Watson for crash dumps generated when a process dies.

    1. Use the drwtsn32 -i command to make Dr. Watson the default debugger.

    2. Open Dr. Watson with the drwtsn32 -i command.

    3. Check all options.

    4. Choose the path where crash dumps are generated.

      When providing crash dumps, collect both the dmp and drwtsn32.log files.

  2. Use the Window Debugging Tools to generate crash dumps of a running process.

    1. Make sure you install the latest version of the Debugging Tools and OS Symbols for your version of Windows.

    2. Set the _NT_SYMBOL_PATH for your environment.

  3. Enable generation of a crash dump for your application.

    Get the process ID of the application using the tlist.exe command, then enable the crash dump.

    win-dbg-root\tlist.exe

    win-dbg-root\adplus.vbs -crash -FullOnFirst -p pid -o C:\dump-dir

    The adplus.vbs command tracks the application with process ID pid. The adplus.vbs command generates a dmp file in the event of a crash.

  4. When collecting crash dump information, take the complete folder generated under C:\dump-dir.

ProcedureTo Run the pkg_app Script

The pkg_app script packages an executable and all of its shared libraries into one compressed tar file given the process ID of the application, and optionally the name of the core file to be opened. The files are stripped of their directory paths, and are stored under a relative directory named app/ with their names only, allowing them to be unpacked in one directory.

On Solaris 9 and Solaris 10, the list of files is derived from the core file rather than the process image if it is specified. You must still provide the process ID of the running application to assist in path resolution.

Two scripts are created to facilitate opening the core file when the tar file is unpacked.

  1. Copy the script to a temporary directory on the system where the server is installed.

  2. Become superuser.

  3. Run the pkg_app script in one of the following ways.

    • ./pkg_app server-pid core-file

    • ./pkg_app server-pid

      The pkg_app script prompts for the core-file name.

    • ./pkg_app core-file