kill — send signals to processes

What it does

kill sends a signal to a process by PID. The default signal is SIGTERM (15), which politely asks the process to terminate — the process can catch it, clean up, and exit gracefully. kill -9 sends SIGKILL, which the kernel enforces immediately and the process cannot catch, ignore, or handle. There is a whole spectrum in between: SIGHUP (1) makes daemons reload configs, SIGINT (2) is what Ctrl-C sends, SIGSTOP (19) freezes a process, SIGCONT (18) resumes it.

Why it matters

Every stuck process, hung service, and runaway job on a Linux box is resolved with kill. But the discipline matters more than the command: you start with SIGTERM and give the process a moment to exit cleanly, and only escalate to SIGKILL when it refuses. kill -9 is a last resort, not a first instinct — a process killed with SIGKILL gets no chance to flush buffers, close files, or tell its children to stop, which is how you end up with corrupted databases and orphaned processes.

What the process does with the signal you sent

Handing a signal to a process is a request against its signal disposition, and there are only three possibilities. Most signals have a default action the kernel carries out unless the program has done something about them: signal(7)'s table lists SIGHUP, SIGINT, SIGTERM, SIGKILL and SIGUSR1 as Term — terminate — SIGSTOP as Stop and SIGCONT as Cont. A program can also install a handler and decide for itself, which is what almost every daemon does with SIGHUP: sshd 'rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name and options it was started with', and nginx's own signal list gives HUP as 'changing configuration'. Finally a program can ignore a signal outright, or block it while it finishes something — and exactly two signals are beyond all of that. signal(7) states it plainly: 'The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.' That one sentence is the whole reason kill -9 always works and is still the last resort: nothing is asked of the process, and nothing is cleaned up.

Example

$ ps -o pid,stat,cmd -p 1009164

    PID STAT CMD
1009164 S    sleep 300

$ kill 1009164

(no output — signal sent)
$ ps -o pid,stat,cmd -p 1009164
    PID STAT CMD
ps exit=1

$ kill -9 1009211

/tmp/killtest.sh: line 21: 1009211 Killed                  sleep 300
    PID STAT CMD
ps exit=1

$ kill -0 1009220 && echo 'PID 1009220 is alive'

PID 1009220 is alive

$ kill -l | head -3

 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
 6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM

$ kill -HUP 1234

(no output — nginx reloaded its config)

Common flags

kill <pid>

send SIGTERM (15) — ask the process to terminate gracefully

kill -9 <pid>

send SIGKILL — kernel terminates it immediately, cannot be caught

kill -HUP <pid>

send SIGHUP (1) — many daemons reload their config

kill -0 <pid>

check if a process exists and is signalable, without sending a real signal

kill -l

list all signal names and numbers

kill -STOP <pid>

freeze a process (SIGSTOP); resume with kill -CONT

killall <name>

signal every process matching a name, e.g. killall nginx — a separate program (psmisc), not part of kill itself, and not present on every minimal system

kill -l <signal>

Translate between a name and a number: kill -l 9 prints KILL, kill -l TERM prints 15. Handy when a log line or a core dump names a signal by number. Note that `kill` is usually a shell builtin, and bash prints the whole numbered table while /bin/kill -l (procps-ng) prints bare names with no numbers.