Signals & Killing Processes
Signals
You can't reach into another process's memory and flip a switch. Instead, Linux lets you send it a signal - a small, standardized asynchronous notification the kernel delivers on your behalf. What the process does with that signal is up to the process itself (unless the signal is one of the two special ones below).
| Signal | Number | Meaning | Catchable? |
|---|---|---|---|
| SIGHUP | 1 | Hang up / reload config | Yes |
| SIGINT | 2 | Interrupt (Ctrl+C) | Yes |
| SIGKILL | 9 | Force kill | No |
| SIGTERM | 15 | Graceful terminate (default) | Yes |
| SIGSTOP | 19 | Pause | No |
| SIGCONT | 18 | Resume | Yes |
"Catchable" is the key distinction. Most signals are just a polite request the receiving program can intercept - a well-behaved server might catch SIGTERM and use it as a cue to finish in-flight requests, close files cleanly, and then exit. SIGKILL (9) and SIGSTOP (19) are different: the kernel enforces them directly, with no cooperation from the target process required or possible - the process cannot ignore, delay, or clean up before a SIGKILL ends it instantly.
| Command | Action |
|---|---|
kill <pid> | Send SIGTERM |
kill -9 <pid> | Send SIGKILL |
kill -HUP <pid> | Reload |
killall nginx | By name |
pkill -u alice | By user |
The name kill is misleading - despite the name, kill with no signal number just sends SIGTERM (a polite "please stop"), which is why the table above needs a separate -9 row for an actual forced kill.
Warning: Always reach forSIGTERM(the plainkill <pid>, signal 15) first, and only escalate toSIGKILL(kill -9) if the process ignores it after a few seconds. The reason isn't etiquette - a process killed withSIGKILLgets zero chance to run its own cleanup: no closing database connections gracefully, no flushing buffered writes to disk, no removing lock files. That can leave corrupted data or orphaned temp files behind, exactly the messSIGTERMexists to avoid.