Kill is a command that exists to send signals to a process. The name comes from the nature of the default signal that it sends which is the TERM (terminate) signal.
You can imagine signals as somewhat analogous to their real life counterparts on road and rail, which are designed by their nature to inform the vehicle of what needs to happen remotely.
When a large number of software processes are running on a Linux server that does not have any form of user interactive interface, there’s no way to directly stop a running process. Signals can be used to achieve that goal. The command is used thus…
kill [-signal] pid
With signal, being optional, as the type of signal to send, and pid meaning the processes’ id number, as reported as pid in top, ps, etc. As typical with the Linux user permissions, a user can only use kill on their own processes, though root can use it on all processes. The signals can be written as either their names or numbers, here’s a list of the main ones below.
Name Number Description
HUP 1 Hangup
INT 2 Interrupt
QUIT 3 Quit
KILL 9 Kill
TERM 15 Terminate
USR1 User defined
USR2 User defined
When sent to kill the name needs to be prefixed with SIG if you want to type that rather than memorise the number. For a full list of signals kill supports on your system type…
Here’s a brief rundown of the listed signals in a little more detail. Something to bear in mind is that obedience to and acknowledgement of most of the signals is dependant on the process itself, it can choose to ignore a signal or may just not support doing anything with it on reception.
First HUP, the name hangup itself is a legacy of the days of multiple terminal systems and the signal was used to tell a terminal session to hang up on the user, clean up after itself and terminate. These days the more common use is with daemons that use it as a signal to reload their config files.
INT is the same signal sent to a process as when you press the ctrl-c key combination. Usually it’s a command for the process to stop what it’s doing, clean up after itself and terminate. Though terminals generally do not terminate but await further instruction from that combination.
QUIT is similar to TERM. On receiving this the process is expected to stop what it’s doing, clean up after itself and then terminate. If it does not then QUIT causes a core dump to be produced.
KILL is the ultimate kill signal, it is not sent to the process at all but rather informs the kernel to terminate the process. As such, no cleanup is performed so if the process would usually save settings on exit etc that won’t be done. Because processes can ignore the other commands that may cause them to terminate a lot of people go straight for this signal but it is better to try for a termination first and only resort to KILL when required.
TERM as with its similarity to QUIT is the instruction to terminate. On receiving this the process is expected to stop what it’s doing, clean up after itself and then terminate.
STOP, like KILL, is sent through to the kernel to handle. This stops execution of the process leaving it in the state it was until either the CONT signal is sent or the KILL signal is received to terminate it.
CONT informs the system to allow a stopped process to continue executing.
USR1 and USR2 are user defined signals, which generally means their meaning will be defined by the process that is receiving the signal. The dd command, for example, uses the USR1 signal as a prompt for it to display it’s progress.
While kill can only be used for individual processes, the killall command does much the same thing but will signal all matching processes based on the process name. For example the following command sends the quit signal to all apache processes:..
killall -3 apache
Knowing how to kill can be very helpful when managing a Linux server, and knowing your signals is the key to killing effectively as opposed to blindly.Save this article