Kill -9 Why You Should Not Use It Unless Absolutely Necessary

It has come to my attention that there is a great wave of people out there that think using kill -9 on everything is a great idea. Who are these people and how did they acquire such an insidious habit? I wish I knew.

There exists in Unix a thing called a signal. There are many types of signals that are sent to processes for a great variety of reasons. When a process receives a signal, it may ignore it or catch the signal and execute a signal
handler. This is called trapping a signal. Untrapped signals have a default action, which are basicly do nothing or exit.
There are two signals that are untrappable, SIGKILL and SIGSTOP.

There is a command line utility called kill that simply sends a signal to a process. kill -signal pid will send signal to pid. kill
-l will list all of the available signals. You’ll notice each signal has a number and a symbolic name. There are three signals commonly used to make a process exit: SIGTERM (15, terminate), SIGINT (2, interrupt), and SIGKILL (9, kill, untrappable, El
Diablo).

Processes Exiting

Most programs require some sort of cleanup when it exits. These programs setup a signal handler to perform these cleanup duties as a result of SIGTERM and SIGINT. They would setup a signal handler for SIGKILL if they could, but SIGKILL is untrappable.

If a program decided to trap the TERM or INT signals, then it would most likely delete any temporary files, shutdown sockets, remove shared memory segments, close open files, or some other task. For instance, MySQL needs to flush data to disk and close its
database files. Killing MySQL with -9 will corrupt your databases. Most user apps that work on some binary formatted data files require temporary files, using kill -9 on these apps would leave around these temporary files. Network daemons need to flush their
logs and properly shutdown Internet sockets so that clients aren’t left hanging. Killing your web browser can corrupt your bookmarks file, cache files, leave temp files in /tmp (remember that 20MB mpeg you clicked on? yah, it’s still sitting in /tmp)

Using kill -9 on a process is like just hitting the power button on your running PC. You already know that powering off a running PC can damage your filesystem because of run-time inconsistent data, why would you do the same thing to your applications? You
risk the _exact same_ data corruption.

How-To

Therefore, so that your important applications may close themselves, it is very important you follow this procedure when killing them:

kill pid (sends a TERM, wait 5 seconds)

kill pid (yes, try again, wait 5 seconds)

kill -INT pid (wait for it)

kill -INT pid (damn, still not dead?)

kill -KILL pid (same thing as -9)

kill -KILL pid (something is wrong)

If the process is still running, then stop sending it signals. It’s either stuck in I/O wait or it’s Defunct. ps auxw | grep processname, if you see it’s in state D, then kill its parent process (the 3rd column of ps
-ef is the parent pid). If it’s in I/O wait, then you have a deeper system problem. Most home users will never have this problem.

Other useful signals include SIGHUP, SIGTRAP, and SIGINT

HUP sends the SIGHUP signal. Some daemons, including Apache and Sendmail, re-read configuration files upon receiving SIGHUP, so the kill command may be used for this too. You should be aware that it’s up to the application developer to implement signal handlers. Almost all signals are ignored by default, the exceptions being obvious like SIGKILL. There is no guarantee that a daemon will re-read a config when given a SIGHUP.
A SIGINT signal can be generated very simply by pressing CTRL+C in most Unix shells.
It is also common for CTRL+Z to be mapped to SIGTSTP, and for CTRL+\ (backslash) to be mapped to SIGQUIT, which can force a program to do a core dump.