The kill escalation ladder
kill PID sends SIGTERM: a request the process can catch to shut down cleanly, flush buffers, finish the in-flight transaction, remove the pidfile. Give it seconds to act. kill -9 sends SIGKILL: the kernel simply stops scheduling the process, no handler runs, and whatever was half-written stays half-written. The professional habit is TERM, wait, then KILL, which is exactly what systemd does on systemctl stop (TERM, then KILL after TimeoutStopSec, default 90s). If a service only dies to -9, that's a bug worth filing, because every reboot is corrupting its state.
Signals as a control channel
Beyond termination, signals are the original daemon API: kill -HUP nginx reloads configuration without dropping connections, -USR1 makes nginx reopen log files (how logrotate works without restarts), and -QUIT asks for graceful worker shutdown. kill -USR1 $(pgrep dd) prints copy progress. Check a daemon's man page before assuming: HUP means "reload" to nginx and "die" to an unprepared process.
Reading exit codes
A process killed by signal N exits with status 128+N, so exit code 137 means SIGKILL (128+9), which in a container context almost always means the OOM killer or a memory limit; 139 is a segfault (128+11); 143 a clean SIGTERM death. Recognising these three numbers on sight turns many mystery crash reports into instant diagnoses. kill -l lists all signals; uncatchable ones are only KILL and STOP.