What is the purpose of the -9 option in the kill command?

Is there a difference between

kill -9 212121

and

kill 212121

The kill command will send a defined signal to a process with a given identity (PID):

kill -<signal> <pid>

Of course we can only kill processes we own, whereas root can kill all processes. See Wikipedia for a nice summary of computing signals.

Signals kill can send are listed in the manpage. The signal can be represented by name or by number. If no signal is given the default signal 15 resp. TERM is used.

All three commands below are therefore identical:

kill -9 1234
kill -KILL 1234
kill -SIGKILL 1234

The difference between SIGTERM and SIGKILL is the way an application may act on the signal:

• TERM: an application will be able to terminate, i.e. properly run a shutdown routine.
• KILL: the applications is stopped and killed immediately (which could lead to data loss or raising apport to report a presumed crash in some cases).

The Ubuntu man page for kill explains the purpose of the -9 switch (admittedly in a rather choppy fashion):

Name     Num   Action    Description
KILL       9   exit      cannot be blocked

Here's what another man page says.

The command kill sends the specified signal to the specified process or process group. If no signal is specified, the TERM signal is sent. The TERM signal will kill processes which do not catch this signal. For other processes, it may be necessary to use the KILL (9) signal, since this signal cannot be caught.

Therefore, using the -9 switch ensures that the process is effectively killed. Even though a frozen or unresponsive process may not respond to a simple TERM signal, it will die when sent a KILL signal.

Note that all of the following are synonymous:

kill -9 1234
kill -KILL 1234
kill -SIGKILL 1234

It's worth pointing out that in the world of signal handling, SIGKILL is one of the few unique ones that is handled by the operating system not the program. When you run kill -9, you're not telling the application to terminate itself, instead you're telling the OS to stop running the program, no matter what the program is doing.

After SIGKILL is sent, the program will immediately be stopped. If any kernel calls are running (e.g. File IO) on the program's behalf, those calls may or may not continue until they finish, depending on the call, but the program itself will not run any more. Note that traced tasks or tasks running under a debugger may behave differently here.

The other signal that can't be blocked is SIGSTOP which has a similar effect, but instead freezes the program; you can send SIGCONT later on to resume it. This behavior is completely controlled by the OS, and the program does not get any prior notification.

All the other signals are sent to the program; it can handle them however it chooses, or if it ignores the signal then a default behavior is followed.

Here are a few useful signals that you may find yourself sending to a process:

• SIGHUP -- hangup
  Tells the program that the user disconnected (e.g. SSH session or terminal window was closed).
  Usually does a graceful shutdown of the program.
• SIGINT -- interrupt
  Sent when you hit CTRL+C
  Usually means "stop what you're doing" -- may or may not kill the program
• SIGTERM -- terminate
  The default sent by kill and killall.
  Usually terminates the program... sometimes after the program finishes whatever it's doing.
• SIGSTOP -- stop
  Sent when you hit CTRL+Z
  Pauses the program, discussed above
• SIGPIPE -- pipe closed
  Tells the program that the the pipeline has closed. Usually terminates the program.
  For example cat /etc/passwd | head -n1 will send SIGPIPE to the cat process after the first line is printed, causing cat to terminate before finishing the whole file.

While all of these signals happen "naturally" in their own setting, you can use the signal to fake a condition to achieve the desired result.

For example, if you want to terminate someone's SSH session you can simply kill the process, but by doing so you'll prevent it from updating its HISTORY file, which may be important for security reasons. But instead if you send it SIGHUP, then the process will assume the connection has died and will perform its standard cleanup.