Tips for Troubleshooting
Troubleshooting Guide
- Application Server
- Sun Java System Application Server 9.1 Troubleshooting Guide - http://docs.sun.com/app/docs/doc/819-3677
- Sun Java System Application Server Enterprise Edition 8.2 Troubleshooting Guide - http://docs.sun.com/app/docs/doc/819-4738
- Sun ONE Application Server 7, Enterprise Edition Troubleshooting Guide - http://docs.sun.com/source/817-2161-10/index.html
- Web Server
- Sun Gathering Debug Data for Sun Java System Web Server - http://docs.sun.com/app/docs/doc/820-2483
- Sun Java System Web Server 7.0 Troubleshooting Guide - http://docs.sun.com/app/docs/doc/820-2209
- SUN Internal - 3 common basic types of problem encountered with Web Server - http://software-tsc.central.sun.com/twiki/bin/view/Products/WebServerTroubleshooting
Common Problems for Data Collection
- No core file produced ( Solaris )
- Self-help
Verify write permission in current working directory and core file
Verify enough space for core file
Verify ulimit -a shows "unlimited" for coredump
Verify coreadm has per-process core dumps enabled - The coreadm output is incorrect
Run coreadm(1M) and make the following recommended settings:
#mkdir -p /var/cores
#coreadm -g /var/cores/%f.%n.%p.core -e global -e process -e global-setid -e proc-setid -e log
#coreadm
global core file pattern: /var/cores/%f.%n.%p.core
init core file pattern: core
global core dumps: enabled
per-process core dumps: enabled
global setid core dumps: enabled
per-process setid core dumps: enabled
global core dump logging: enabled - Java specific 1 :
The process received SIGSEGV or SIGILL but no core dump produced. May be the process handled it. For example, HotSpot VM uses the SIGSEGV signal for legitimate purposes such as throwing NullPointerException, deoptimization etc.
Not all SIGSEGVs are bad! Only if the current instruction (PC) falls outside JVM generated code, the signal is unhandled by the JVM. Only in such cases, HotSpot dump core. - Java specific 2:
The JNI Invocation API was used to create the VM. The standard Java launcher was not used. The custom Java launcher program handled the signal by just consuming it and produced the log entry silently.
This has been seen with certain AppServers, WebServers. These JVM embedding programs transparently attempt to re-start (fail over) the system after abnormal termination.
Not producing core is a feature and not a bug The above two are taken from section 3.2.3 in http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf - The coreadm output is correct but there is no core file generated when the application server or web server running in SSL mode crashed.
For application server
put the following statement "SSL_DUMP=1; export SSL_DUMP" in the startserv script of ( DAS or instance )
For web server issue documentation http://sunsolve.central.sun.com/search/printfriendly.do?assetkey=1-9-63420-1 http://sunsolve.central.sun.com/search/printfriendly.do?assetkey=1-25-72079-1 - Java thread dumps are not generated while performing "Ctrl and \ keys" are pressed, "kill -3" or "kill -QUIT" command.
- Ensure the -Xrs option is not enabled in the Java flags/switch
- For application server 9.x, please use the following command : asadmin generate-jvm-report
- On windows the equivalent key sequence is the Ctrl and Break keys. If you can't get the console, please ensure to install
- Self-help