3

We use the regular /etc/init.d/jboss stop to stop the jboss on our machines. But at times, it does not stop the process and we get what is pasted below. When this happens we kill the process with a kill -9. Could this be a bug in the application code or could it be an OS level issue that can be fixed?

waiting for processes to stop/usr/local/jboss/bin/run.sh

waiting for processes to stop/usr/local/jboss/bin/run.sh

waiting for processes to stop/usr/local/jboss/bin/run.sh
/usr/local/jboss/bin/run.sh

Timeout: Shutdown command was sent, but process is still running with PID 7252
[root@mercury02 ~]#  

P.S: I opened the /etc/init.d/jboss file and as expected, it tries to send kill -15 when using stop.

5

It's not quite that SIGTERM isn't working, it's that the application doesn't react to it the way you are hoping. Generally, the purpose of catching SIGTERM is to do some tidying up, such as syncing data to disk, etc., before exiting.

There's no enforced requirement, however, that the process actually exit, so if something goes wrong during whatever it does in response, it may not.

SIGKILL (kill -9), on the other hand, cannot be caught and should force the process to stop unless for some very unusual reason it is uninterruptible (a reason it could not voluntarily produce). The problem with this is it means the process cannot react and do whatever little things it needs to do before shutting down. That may mean it has left data on disk in an inconsistent state, etc.

Hence, the normal and preferred way to kill a process is SIGTERM. Only if that fails should you resort to SIGKILL, and in that case, you should wonder why it is necessary, because a correctly functioning application should not need this. In other words...

Could this be a bug in the application code

Yes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.