[jboss-jira] [JBoss JIRA] Updated: (JBAS-4287) run.sh can consume 100% single CPU resources on Solaris
[ http://jira.jboss.com/jira/browse/JBAS-4287?page=all ]
Ian Springer updated JBAS-4287:
-------------------------------
Attachment: run.sh.patch
It turns out the /bin/wait alias was not a viable solution. Based on my testing on a
Solaris 9 box, Solaris' /bin/sh does not have a wait builtin, so it is using
/usr/bin/wait (or whatever wait is in the PATH) by default. And /usr/bin/wait and
/bin/wait are both shell scripts that delegate to ksh's wait builtin, which apparently
does not support the 127 exit status for non-existent processes. So it looks like the best
way to go here is to remove the -ne 127 check and the while loop altogether. I've
attached a patch to that effect. I have tested it under Cygwin.
run.sh can consume 100% single CPU resources on Solaris
-------------------------------------------------------
Key: JBAS-4287
URL: http://jira.jboss.com/jira/browse/JBAS-4287
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Other
Affects Versions: JBossAS-4.0.5.GA
Environment: Solaris on SPARC (version 9 & 10)
Reporter: Quenten Alick
Attachments: run.sh.patch
When shutting down jboss the run.sh script remain alive and consumes 100% of a single
CPUs resources. run.sh needs to be killed off.
To trigger the bug, you need to
1) set LAUNCH_JBOSS_IN_BACKGROUND
2) start the jboss server normally
3) Once it's started stop the server
At this point the JVM stops, however the run.sh script remains running consuming 100% of
a single CPUs resources.
The problem seems to be this bit of script, plus the fact that the script shebang is
#!/bin/sh
while [ "$WAIT_STATUS" -ne 127 ]; do
JBOSS_STATUS=$WAIT_STATUS
wait $JBOSS_PID 2>/dev/null
WAIT_STATUS=$?
done
On Solaris, /bin/sh is *real* bourne shell and the wait shell-built-in for /bin/sh on
Solaris returns 0 (not 127) if the PID (passed as an argument) doesn't exist. The man
page for wait states that this is the correct behaviour. Therefore wait returns 0 and the
while loop continues forever burning up CPU resources (until you kill it with one of the
signals not being trapped).
Here's a link to the patch that may have introduced the bug.
http://jira.jboss.com/jira/browse/JBAS-3748
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira