Signals: kill, TERM vs KILL

Ask nicely before you force it.

You control running processes by sending them signals — small messages the kernel delivers. The command is kill (a slightly misleading name, since most signals are not fatal). The two you use constantly are SIGTERM (15), a polite "please shut down," and SIGKILL (9), a forcible "stop now." The order matters: TERM lets a process finish its work, flush data, and release locks; KILL gives it no chance to do any of that.

$ kill 812              # sends SIGTERM (15) by default — ask nicely first
$ kill -15 812          # the same, explicit
$ kill -9 812           # SIGKILL — forcible, only if TERM did not work
$ pkill nginx           # by name instead of PID
$ kill -HUP 812         # SIGHUP: many services reload their config on this

Why -9 is a last resort

SIGKILL cannot be caught or handled — the kernel just stops the process immediately. That sounds convenient, but it means the process cannot save state, finish writing a file, or clean up: you can end up with corrupted data, a half-written file, or a stale lock that stops the service from restarting. Always send SIGTERM first and give it a few seconds; reach for -9 only when a process is genuinely hung and ignoring the polite request. This is exactly why docker stop waits before force-killing.

Other useful signals

A few more earn their keep. SIGHUP (1) traditionally means "reload" — many daemons re-read their config on it without a full restart. SIGSTOP and SIGCONT pause and resume a process (handy for freezing something suspicious without killing it — a technique the incident-response lessons use). And a process exiting with a non-zero status, or being killed by a signal, is how the shell and systemd know something went wrong, which ties back to why exit codes matter in scripts and pipelines.