This technote explains what must be done to ensure that a
core file is produced on Solaris Operating System™ when the Java™ Virtual
Machine (JVM™) crashed.
If you have already contacted support, continue on to the
component-specific MustGather information. Otherwise, click: MustGather:
Read first for all WebSphere Application Server products.
Crash specific MustGather information
- Make sure that in /etc/system that the parameter sys:coredumpsize is
not set to 0.
- Ensure that your ulimit -c is set high enough. Units are in 512 byte
blocks. It is best to set at unlimited and ensure that you have
enough free file system space in WebSphere\Appserver\bin (at least 750 MB
to 2 GB).
Note: ulimit -a displays your current ulimit settings.
- Ensure that the WebSphere\Appserver\bin directory is writable by the
WebSphere® Application Server process.
- Test for getting a core file by issuing a kill -11 against the
PID of the Java process, or by using the gcore command to generate a core
file.
- If you still do not get a core file after setting these parameters
correctly, do the following, or refer to Additional Instructions:
- If you cannot get a core from test, determine if you can obtain
a core file from any process on the machine.
- If you can get a core from the test, you can wait for a crash
to occur during error condition.
Additional Instructions
For Solaris 2.6 or earlier, use the following instructions:
- It is possible that the dump area is too large. There have been some
problems observed if the dump partition is larger than 2GB.
- If the dump area is not on a regular disk, that is, if it is on a disk
managed by Veritas or Disk Suite, the core is not produced if Veritas or
Disk Suite is not up and running when the core must be taken. There is
similar behavior if the dump area is on an NFS client and the NFS software
is not functional when the crash occurs.
For Solaris 2.7 or later, including Solaris 8 and Solaris 9, use these
instructions:
The Solaris operating system attempts to create up to two core files for
each abnormal-ending process. One is a core file that uses a global core
file name pattern; the other uses a per-process core file name pattern.
These actual files use directory information to determine the location of
the resulting core files.
The core file name pattern and directory path is configured using the
coreadm command. By default, the
global core file pattern is disabled and not used, and the per-process
core file pattern is set to core. Therefore, by default, the operating
system attempts to create a core file named core in the process's current
working directory.
Run the command coreadm to set the location of the core file. Following
is the list of parameters you can set for the core file. Use this
information to determine if core files are enabled and where the core file
is to be written.
global core file pattern:
/var/core/core.%f.%
init core file pattern: core
global core dumps: enabled
per-process core dumps: enabled
global setid core dumps: enabled
per-process setid core dumps: disabled
global core dump logging: disabled |
Note: Search for core files in the following directories:
- install_root/bin.
- Configured AppServer working directory.
- /tmp
If you cannot find a core file, search the entire machine for core* files.
3. Follow instructions to send
diagnostic information to IBM support.
Useful references:
Solaris core files:
http://docs.sun.com/db/doc/816-0219/6m6njqb72?a=view
Solaris OS signals:
http://docs.sun.com/db/doc/816-0218/6m6nirqnq?a=view
Solaris 9 coreadm features:
http://docs.sun.com/db/doc/806-4074/6jd68pq4l?a=view
Solaris 2.8 coreadm features:
http://docs.sun.com/db/doc/805-7229/6j6q8svhr?a=view
Solaris 2.7 coreadm features:
http://docs.sun.com/db/doc/806-1650/6jau1364s?a=view
For a listing of all technotes, downloads, and educational materials
specific to the Java SDK component, search the WebSphere
Application Server support site.
|