A process hang is defined as one of the Web Server processes not responding to requests while the httpd process is still running.
Make sure that you collect all the data over the same time frame in which the problem occurs. See 1.6 Configuring Solaris to Generate Core Files if a core file is not generated.
Gather the following information for process hang problems. Run the commands in the order when the problem occurs. Be sure to specify the time when the process hanged and list the affected processes, if possible.
Gather the general system information as explained in To Gather General Debug Data for Any Web Server Problem.
For Solaris, use the ptree command on the uxwdog process to find about the process.
If you are using Web Server 6.1 or Web Server 7.0, instead of the uxwdog process, use the webservd-wdog process.
ptree 11449 11449 ./uxwdog -d /prods/crypto/60SP6/https-sun/config 11450 ns-httpd -d /prods/crypto/60SP6/https-sun/config 11451 ns-httpd -d /prods/crypto/60SP6/https-sun/config
Gather the data on the highest PID process, which in this example is 11451. The Web Process is either ns-httpd or webservd, depending on the Web Server version.
Run the netstat command and save the output.
netstat -an | grep web-port
(For Solaris), wshang script captures the debug data.
The wshang script is available at: http://www.sun.com/bigadmin/scripts/indexSjs.html
Run the script pkg_app on one of the core file generated by the wshang script. For more information on how to run thewshang script, see To Run the wshang Script.
Run the following commands and save the output.
ps -aux server-root vmstat 5 5 iostat [ -t ] [ interval [ count ] ] top uptime
ps -aux server-root vmstat 5 5 iostat [ -t ] [ interval [ count ] ] top sar
ps -aux server-root vmstat 5 5 top uptime sar
Obtain the WEB process PID:
Obtain the process details of the WEB running process PID:
Get the swap information.
Already provided in C:\report.txt as described in To Gather General Debug Data for Any Web Server Problem.
If the Web Server uses a Directory Server, provide the access, errors and audit logs of the Directory Server used by the Web Server.
The paths of these logs files are specified by the following parameters in the dse.1dif file.nsslapd-accesslog,nsslap-errorlog, and nsslapd-auditlog
The dse.1dif file is located in the config directory.
(For Solaris) If you are able to isolate the hanging process, get the following debug data for that process. Otherwise, get the following data for each of the Web Server processes.
Using the PID obtained in Step 3, get a series of five of the following commands (one every 10 seconds) :
pmap -x web-pid
Additionally, get the outputs of the following commands:
prstat -L -p web-pid
Search for any core file that could have been dumped by one of the Web Server processes. If you find one, see To Gather Debug Data on Web Server Crashed Process.
Get the output of the following command.
truss -ealf -rall -wall -vall -o /tmp/WEBProc-PID -p web-pid
tusc -v -fealT -rall -wall -o /tmp/WEBProc-PID -p web-pid
strace -fv -o /tmp/WEBProc-PID.strace -p web-pid
Use DebugView tool. You can download this tool from http://www.sysinternals.com/Utilities/DebugView.html
Wait for a minute after launching the appropriate command (truss, strace, tusc, or DebugView) then stop it by pressing Control+C in the terminal where you launched the command.
Get core files and the output of the following commands.
If a process hangs, it is helpful to compare several core files to review the state of the threads over time. Make a copy of the core file to a new name, wait for approximately one minute then rerun the following commands, so that the core files are not overwritten. Do this three times to obtain three core files.
For HP-UX, you need PHKL_31876 and PHCO_32173 patches to use the gcore command. If you cannot install these patches, use the HP-UX /opt/langtools/bin/gdb command from version 3.2 and later, or the dumpcore command.
cd server-root/bin/https/bin;gcore -o /tmp/web-core web-pid;pstack /tmp/web-core
# cd server-root/bin/https/bin gcore -p web-pid (gdb) attach web-pid Attaching to process web-pid No executable file name was specified (gdb) dumpcore Dumping core to the core file core.web-pid (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: , process web-pid
The core.web-pid should be generated in the web-identifier/config directory.
# cd server-root/bin/https/bin gdb (gdb) attach web-pid Attaching to process web-pid No executable file name was specified (gdb) gcore Saved corefile core.web-pid (gdb)backtrace (gdb)quit
Get the WEB process PID:
Generate a crash dump on the WEB running process PID:
C:\windbg-root>adplus.vbs -hang -p web-pid -o C:\crashdump_dir
For Windows, provide the complete generated folder under C:\crashdump_dir.
For Solaris, Archive the result of the script pkg_app (at least one core file is required).
./pkg_app.ksh -c [pid-of-application or corefile] -p <full path to process binary of webservd>
The Sun Support Center requires the output from the pkg_app script to properly analyze the core file(s). For more information on how to run the pkg_app script, see To Run the pkg_app Script
Make sure that the appropriate limitations are set by using the ulimit command, and that the user is not nobody. Also check the coreadm command for additional control. See 1.6 Configuring Solaris to Generate Core Files if a core file is not generated.
If you are using Web Server 6.1 or Web Server 7.0, do not proceed further with the next step.
For UNIX and Linux, If JVM is used for the Web applications, provide the JVM Stack traces during a hang situation.
A series of three to five Stack traces will be required.
To enable thread dumps for version 6.0, perform the following steps:
Edit the configuration file
Modify the following line
Init fn="NSServletLateInit" LateInit=yes
Init LateInit="yes" fn="NSServletInit" CatchSignals="yes" Signals=SIGQUIT
Add or modify the following line in /server-root/https-host/jvm12.conf
Restart Web Server.
When a problem occurs during a restart, issuing a kill —3 against the process dumps the stack traces into the Web Server errors log.