Asking Nicely
SIGTERM (Signal 15) — The Standard Termination Request
SIGTERM is the default signal sent by kill <PID> when you don't specify a signal number — kill <pid>, kill -15 <pid>, and kill -TERM <pid> are all equivalent ways to send it. It is a request, not a command.
The process receives SIGTERM and can:
- Catch it, perform cleanup (flush buffers, close connections, write a PID file removal), then exit gracefully.
- Ignore it entirely (though this is poor practice for production software).
Well-behaved daemons — nginx, postgresql, redis — all catch SIGTERM and perform graceful shutdown: they stop accepting new connections, finish in-flight requests, and then exit cleanly. This is why container orchestrators like Kubernetes send SIGTERM first and wait up to 30 seconds (the terminationGracePeriodSeconds) before escalating.
SIGHUP (Signal 1) — Reload Configuration
SIGHUP originally meant "the terminal connection hung up" (from the era of dial-up modems). When a terminal disconnected, the kernel sent SIGHUP to all processes in that terminal session, telling them their controlling terminal was gone.
Today, SIGHUP has been repurposed by convention: sending it to a daemon tells it to reload its configuration file without restarting — nginx, for instance, can be told to reload either by sending SIGHUP directly to its PID or via the equivalent systemctl reload nginx.
This works because nginx has a custom SIGHUP handler that re-reads nginx.conf, validates it, and gracefully replaces worker processes — all without dropping existing connections. This is how you deploy config changes to production with zero downtime.