jboss7 giving 2 PID's
 

Hi Linux Guru's

We have a running jboss7 app from our servers, I am just wondering although our dev people has a strong stop-start jboss script, we still got an output of two PID's after the start of jboss7. So we just assumed the old PID becomes on stale state but we are still not sure. May I know is there anyone encounter this same situataion? Does the "what-we-so-called stale PID" still eat memory resources of the server?


[pogi@gorgeous_server log]$ ps -ef | grep standalone
pogi 10664 6724 0 22:27 pts/1 00:00:00 grep standalone
pogi 14114 1 0 Mar10 ? 00:00:00 /bin/sh /opt/pogi/pkg/jboss-pogi/bin/standalone.sh -c=standalone.xml -b=0.0.0.0
pogi 14207 14114 99 Mar10 ? 4-21:59:53 /opt/pogi/pkg/sunjdk6_25/bin/java -D[Standalone] -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms12G -Xmx12G -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/pogi/log -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml -Djava.io.tmpdir=/opt/pogi/.cache -Xloggc:/opt/pogi/log/gc.log -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Dorg.jboss.boot.log.file=/opt/pogi/pkg/jboss-pogi/standalone/log/boot.log -Dlogging.configuration=file:/opt/pogi/pkg/jboss-pogi/standalone/configuration/logging.properties -jar /opt/pogi/pogi/jboss-pogi/jboss-modules.jar -mp /opt/pogi/pkg/jboss-pogi/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir=/opt/pogi/pkg/jboss-pogi -c=standalone.xml -b=0.0.0.0
pogi 10664 6724 0 22:27 pts/1 00:00:00 grep standalone
pogi 14344 1 0 Mar8 ? 00:00:00 /bin/sh /opt/pogi/pkg/jboss-pogi/bin/standalone.sh -c=standalone.xml -b=0.0.0.0
pogi 23421 14114 99 Mar8 ? 4-21:59:53 /opt/pogi/pkg/sunjdk6_25/bin/java -D[Standalone] -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms12G -Xmx12G -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/pogi/log -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml -Djava.io.tmpdir=/opt/pogi/.cache -Xloggc:/opt/pogi/log/gc.log -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Dorg.jboss.boot.log.file=/opt/pogi/pkg/jboss-pogi/standalone/log/boot.log -Dlogging.configuration=file:/opt/pogi/pkg/jboss-pogi/standalone/configuration/logging.properties -jar /opt/pogi/pogi/jboss-pogi/jboss-modules.jar -mp /opt/pogi/pkg/jboss-pogi/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir=/opt/pogi/pkg/jboss-pogi -c=standalone.xml -b=0.0.0.0

Going by the pids/ppids, the startup script is the one launching both instances.

The fact that the start times are days apart makes me suspicious that the start script is a bit dodgy, also I would expect the start script to daemonise the JBoss process and exit, not hang around. It may be worth finding a better start script...