Linux + Bash Scripting
20 min
Day 9: Processes & signals
Signals: how Linux asks a process to do something, politely or not
A signal is a small, standardized interrupt sent to a process. SIGTERM (15) politely asks a process to shut down — a well-behaved program catches it, cleans up (closes DB connections, finishes in-flight requests), and exits. SIGKILL (9) is not a request — the kernel terminates the process immediately, with no chance to clean up.
Working with processes and signals
ps aux | grep node
kill -TERM 4821 # ask nicely
kill -9 4821 # SIGKILL — no cleanup, immediate
pkill -f "node server.js"Why this matters for Kubernetes later
When Kubernetes terminates a pod, it sends SIGTERM, waits up to terminationGracePeriodSeconds, then SIGKILLs anything still running. An app that doesn't handle SIGTERM gets hard-killed mid-request every single rollout — a very common source of dropped requests during deploys (Phase 8).
- SIGTERM (15) — graceful shutdown request, catchable
- SIGKILL (9) — immediate termination, not catchable
- SIGINT (2) — what Ctrl+C sends
- SIGHUP (1) — traditionally "config changed, please reload"
Key terms
- Signal
- A small asynchronous notification sent to a process, e.g. to request termination.
- SIGTERM
- A catchable request to terminate gracefully.
- SIGKILL
- An uncatchable, immediate termination — no cleanup runs.
Why can a well-written server catch SIGTERM but never SIGKILL?
