|
Problem(Abstract) |
This document outlines what needs to be done to ensure
that a full core file is produced on AIX® if WebSphere® Application Server
crashes. Gathering this information before calling IBM® support helps
familiarize you with the troubleshooting process and saves you time. |
|
Resolving the
problem |
The following steps ensure that AIX is set up to accept a
full core:
- Go into SMIT and ensure that full core is enabled; or, from a
command line:
lsattr -Elsys0|grep full |
|
To set full core to true: |
|
chdev -a fullcore=true
-lsys0 |
|
- Ensure that your ulimit -c and ulimit -f is set high
enough. Note that units are in 512-byte blocks. Set to unlimited to
ensure that you have enough free file system space in your
install_root\bin directory (at least 750 MB to 2
GB).
To check the current settings run the following commands:
ulimit -c
ulimit -f |
|
To set to unlimited, run the following commands: |
|
ulimit -c unlimited
ulimit -f unlimited |
|
- Ensure that the WebSphere® Application Server process can write to the
install_root\bin directory (default), unless the
workingDirectory variable is changed.
- Check /etc/security/limits file. The stanza for the user that
runs the process should have fsize = -1 and core = -1.
Setting these values to -1 changes the setting to unlimited; you
must ensure that you have enough free space to handle a large core file.
- If the file size is truncated at 2 GB, this may be due to a limitation
of the standard file system on AIX. To work around this limitation use the
Large File Enabled option when adding a journaled filesystem. Refer to AIX
documentation for additional details.
- Issue a kill -11 (against PID of the Java™ process) to test
getting a core file.
- If you still do not get a core file after setting these parameters
correctly, do the following:
- Add the following lines to the beginning of startServer.sh:
|
DISABLE_JAVADUMP=true
export DISABLE_JAVADUMP |
|
- Restart all WebSphere Java processes.
- Issue a kill -3 against the PID of the Java process to test
getting a core file.
Note: Normally a kill -3 generates a
javacore.txt file. However, setting
DISABLE_JAVADUMP=true causes a kill -3 to generate a
system core file.
- If you can get a core from the test, wait for a crash to occur during
an error condition
- If you are using WebSphere MQ, it might trap the signal and not
propagate to the Java process. Disable WebSphere MQ signal handling by
setting the following environment variable.
Example:
|
export
MQS_NO_SYNC_SIGNAL_HANDLING=true |
|
- If the core file is still not generated, use the attached
pdump.sh script that you can run against the process prior to
running the kill command. This will create a file
pdump.java.###.txt file. Locate the line containing sigcatch ( #
grep -p sigcatch pdump.java.*). If SEGV is listed in output, then
something is handling this signal.
Example:
Note: Search for core files in the following directories:
- install_root/bin
- Configured Application Server working directory.
- /tmp
If you cannot find a core file in any of these locations, search your
entire machine for core* files. |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
WebSphere Application Server - Express |
Hangs/performance degradation |
AIX |
6.0, 5.1, 5.0 |
|
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|
|