Processes, Services and Signals

Processes

Every running program is a process with a PID. Useful commands:

ps aux | grep nginx          # find processes
top        # or htop          live CPU and memory per process
kill 1234                    # send SIGTERM (polite stop) to PID 1234
kill -9 1234                 # SIGKILL: immediate, can't be caught; last resort

Services with systemd

On most Linux servers, long-running services are managed by systemd:

sudo systemctl status nginx      # running? recent log lines
sudo systemctl restart nginx
sudo systemctl enable nginx      # start at boot
journalctl -u nginx -f           # follow the service's logs

Signals and graceful shutdown

When systemd, Docker or Kubernetes stops a process, it first sends SIGTERM, waits for a grace period (10 s in Docker, 30 s in Kubernetes by default), then sends SIGKILL. A well-behaved service catches SIGTERM, stops accepting new work, finishes in-flight requests and exits. Without that, every deployment drops requests.

cleanup() {
  echo "SIGTERM received: stop accepting work"
  echo "finishing 2 in-flight jobs..."
  echo "clean exit"
  exit 0
}
trap cleanup TERM

echo "worker started"
kill -TERM $$          # simulate 'docker stop' sending SIGTERM to us
echo "never printed"

worker started
SIGTERM received: stop accepting work
finishing 2 in-flight jobs...
clean exit

In containers, the process that receives SIGTERM is PID 1. A shell-form Docker CMD (CMD node app.js) makes /bin/sh PID 1, and it doesn't forward signals; use the exec form (CMD ["node", "app.js"]).