Signals and kill

Signals are integers. Each has a default action and can be overridden. The kernel delivers a signal by setting a pending-signal bit in the process’s task structure. On the next trip through the kernel scheduler, the pending signal is checked and dispatched.

A process can register a signal handler — a function that runs instead of the default action. It can also ignore a signal (SIG_IGN). The exceptions are SIGKILL (9) and SIGSTOP (19/17): these can never be caught, blocked, or ignored. The kernel always handles them directly.

Key signals and their defaults:

kill PID sends SIGTERM (15) — the polite shutdown request. Despite the name, kill does not forcibly terminate anything by default. It sends SIGTERM, which the process can catch to run cleanup: flush write buffers, close database connections, finish in-flight requests, write a PID file tombstone.

kill 1843          # send SIGTERM to PID 1843
kill -15 1843      # same, explicit signal number
kill -SIGTERM 1843 # same, explicit signal name
kill -TERM 1843    # same, short name

If the process has registered a SIGTERM handler, it runs that function. If not, the default action (terminate) runs immediately. Well-behaved daemons (nginx, postgres, redis) always catch SIGTERM and shut down cleanly.

kill -9 PID sends SIGKILL — the unconditional terminate. The kernel delivers SIGKILL directly without ever entering user space. No handler can intercept it. The process gets no opportunity to flush buffers, close connections, or clean up temp files.

kill -9 1843       # SIGKILL — immediate, no cleanup
kill -KILL 1843    # same, by name

When to use SIGKILL: only after SIGTERM has failed and the process is genuinely stuck (blocking in uninterruptible kernel code, ignoring SIGTERM, or already a zombie). The standard sequence:

kill 1843          # SIGTERM — give it time to clean up
sleep 5
kill -0 1843 2>/dev/null && kill -9 1843   # SIGKILL only if still alive

kill -0 does not send a signal — it checks whether the process exists and you have permission to send it signals. Exit code 0 means it still exists.

pkill and killall send signals by process name, not PID. Useful when you don’t want to look up the PID first.

pkill nginx         # SIGTERM to all processes named "nginx"
pkill -9 nginx      # SIGKILL to all processes named "nginx"
pkill -u alice      # SIGTERM to all processes owned by user alice
pkill -f 'python train.py'  # match against the full command line

killall nginx       # same as pkill nginx on Linux (BSD behaviour differs)

pkill matches against the process name field (truncated to 15 chars on some kernels). -f matches the entire command line, which is more precise. Always test what pkill -l nginx (or pgrep nginx) matches before sending a signal to avoid surprises.

pgrep nginx         # list PIDs that would be hit — no signal sent
pgrep -l nginx      # list PIDs + names

SIGHUP (1) is the reload signal. Originally it meant “the terminal hung up.” Daemons repurpose it: when they receive SIGHUP they re-read their configuration file without restarting. This is how you tell nginx, sshd, or rsyslogd to pick up config changes without dropping connections.

kill -HUP $(pgrep nginx)       # tell nginx to reload config
kill -1 $(cat /var/run/nginx.pid)   # same via PID file

SIGINT (2) is what Ctrl-C sends to the foreground process group. The shell generates it and the kernel delivers it to every process in the foreground group simultaneously. A process that ignores SIGINT will not respond to Ctrl-C.