Kill

  • Generally, you should use kill (short for kill -s TERM, or on most systems kill -15) before kill -9 (kill -s KILL) to give the target process a chance to clean up fter itself. (Processes can't catch or ignore SIGKILL, but they can and often do catch SIGTERM.) If you don't give the process a chance to finish what it's doing and clean up, it may leave corrupted files (or other state) around that it won't be able to understand once restarted.

  • Generally, you should use kill (short for kill -s TERM, or on most systems kill -15) before kill -9 (kill -s KILL) to give the target process a chance to clean up fter itself. (Processes can't catch or ignore SIGKILL, but they can and often do catch SIGTERM.) If you don't give the process a chance to finish what it's doing and clean up, it may leave corrupted files (or other state) around that it won't be able to understand once restarted.

    • strace/truss, ltrace and gdb are generally good ideas for looking at why a stuck process is stuck. (truss -u on Solaris is particularly helpful; I find ltrace too often presents arguments to library calls in an unusable format.) Solaris also has useful /proc-based tools, some of which have been ported to Linux. (pstack is often helpful).

SIGTERM vs SIGKILL

  • SIGKILL is a higher process killing a lower one, such as a kernel shutting down one of the applications that is currently running
  • SIGTERM is a request to the runner of the application to shut itself down.
  • analogy: we humans are the running of the application, and there is boss above us, giving us commands. SIGTERM would be the boss telling us to shut it down, which we then carry out. This is better, because I have information about what I'm currently working on that will allow me to shut down my process gracefully (ie. without losing data). Sometimes the runner of the application is not in a state where they can shut themselves down. SIGKILL on the other hand is like the boss coming by and forcefully shutting down my computer. The SIGTERM never knew about it, so it's possible something got screwed up while the runner (us) was in the middle of working on something.