We are having an internal debate about this. Running jboss eap 7 on RHEL.
We currently have a script to stop the server by simply running kill -9 on the java process.
My suggestion was to use the proper jboss command to shut down:
jboss-cli --connect --commands=:shutdown
How are we ensured that jboss gracefully closed from a kill? I am pushing to use the jboss command.
If the software is non-trivial and comes with a documented means of shutting it down, as appears to be the case here, go with whatever that is. (There may be multiple options.)
Regarding SIGKILL (signal 9) specifically, there's nothing graceful about it.
The target process cannot intercept and handle this signal; it's just immediately terminated without getting to finish up what it was doing or do any cleanup that it would normally do before shutting down.
As for signals in general, if the goal is some form of graceful shutdown look into how the software handles SIGTERM and/or SIGINT. Software at least has the possibility of taking these into account and gracefully shutting down.
SIGKILL should be considered a last resort when gracefully shutting down the service does not work.
Just assume every gun is loaded and every application is signal 9 unsafe. Assuming otherwise you would very likely waste a huge amount of time in debugging occasional malfunctions, caused by things as simple as a forceful shutdown that happened to be issued during log file rotation.
Being signal 9 safe means limiting state changes to atomic transactions, and very few stateful applications really do that.
In the java world, you will not get around occasinally killing something that went stuck. But your primary method of shutting down an application should be the graceful one and ever< failure to shutdown through that method should receive at least the same scrutiny as any other bug in your software stack.
According to official RedHat doc, signals SIGHUP, SIGINT and SIGTERM trigger gracefull shutdown. SIGKILL (kill -9) does not.
