Frequently Asked Question

Why does SIGKILL always work but SIGTERM sometimes doesn't?

Most signals can be caught, the process can install a handler that runs instead of the default action, or ignored outright. SIGTERM is catchable on purpose: that is what makes it polite. A well-written daemon catches SIGTERM, closes its sockets, flushes its buffers, removes its PID file, and then exits with a clean status. A misbehaving or stuck process can simply ignore SIGTERM and keep running.

SIGKILL (9) and SIGSTOP (19) are the two exceptions. The kernel intercepts them before they reach the process: SIGKILL deletes the process unconditionally, and SIGSTOP suspends it. They cannot be caught, ignored, or blocked. The one situation where even SIGKILL appears to fail is a process stuck in the D (uninterruptible sleep) state, usually because it is waiting on a wedged disk or NFS server, the process is technically still in the kernel and won't see the signal until it returns to user space.