Details
-
Suggestion
-
Resolution: Fixed
Description
Modern operating systems have been improving the efficiency of system startup and system shutdown. One leading edge example of this is Fedora. The JIRA shut down script:
.../bin/shutdown.sh
Or:
.../bin/catalina.sh stop
Will take some time to complete, but even after it exits successfully, the JIRA process is still running for several seconds after:
[jira@wcarh034]~% bin/jira-service stop Detecting JVM PermGen support... ^PPermGen switch is supported. Setting to 256m If you encounter issues starting up JIRA Standalone Edition, please see the Troubleshooting guide at http://confluence.atlassian.com/display/JIRA/Installation+Troubleshooting+Guide Using CATALINA_BASE: /evolution/tools/jira/current Using CATALINA_HOME: /evolution/tools/jira/current Using CATALINA_TMPDIR: /evolution/tools/jira/current/temp Using JRE_HOME: /usr/java/jdk Using CLASSPATH: /evolution/tools/jira/current/bin/bootstrap.jar ^P [jira@wcarh034]~% ps -ef | grep jira jira 3472 1 0 Nov21 ? 00:06:55 /usr/java/jdk/bin/java -Djava.util.logging.config.file=/evolution/tools/jira/current/conf/logging.properties -XX:MaxPermSize=256m -Xms128m -Xmx256m -Xms512m -Xmx768m -XX:+UseParallelOldGC -XX:ParallelGCThreads=2 -XX:+UseBiasedLocking -XX:-UsePerfData -Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/evolution/tools/jira/current/common/endorsed -classpath /evolution/tools/jira/current/bin/bootstrap.jar -Dcatalina.base=/evolution/tools/jira/current -Dcatalina.home=/evolution/tools/jira/current -Djava.io.tmpdir=/evolution/tools/jira/current/temp org.apache.catalina.startup.Bootstrap start postgres 3485 2151 0 Nov21 ? 00:00:32 postgres: jira jira 127.0.0.1(53473) idle postgres 3562 2151 0 Nov21 ? 00:00:30 postgres: jira jira 127.0.0.1(50060) idle postgres 3617 2151 0 Nov21 ? 00:00:00 postgres: jira jira 127.0.0.1(50160) idle root 8828 8804 0 10:26 pts/0 00:00:00 su - jira jira 8829 8828 0 10:26 pts/0 00:00:00 -zsh jira 8908 8829 0 10:27 pts/0 00:00:00 ps -ef
If the operating system completes the shutdown scripts and enters the kill process phase before JIRA has shut down, it seems that lock files for $CATALINA_PID and/or JIRA home can be left around leading to every manual reboot becoming an unclean shutdown case.
This issue does not happen on slow machines, or configurations that take a long time to shut down. For our case, it happens every time.
I am considering adding a "sleep N" in our bin/jira-service shutdown wrapper to avoid the problem.
Attachments
Issue Links
- is duplicated by
-
JRASERVER-20311 .jira-home.lock not removed when restarting Windows in a virtualised environment
-
- Closed
-
- relates to
-
-
- Closed
-