SIGSTOP and SIGKILL
Sometimes you can find interesting things to post about just by looking at what people are searching for. Here’s an interesting search query that I thought I’d address, because I certainly understand wanting to understand the “why” of things just as much as the “how”. Today’s query is:
“why sigkill and sigstop signals cannot be ignored by a process in linux”.
The short answer is, because the process never even sees these signals. They control program execution.
Signals are, as I’ve mentioned, a form of interprocess communication – telling a program that some action is required of it. But don’t forget that while programs can receive and act on signals, the Operating System (Linux, in this case) is the entity that is responsible for dispatching these signals. Also don’t forget that a process is entirely and completely under the control of the kernel, and exists only at its forebearance.
When the kernel receives (or sends, even) an SIGKILL signal, it treats it as a signal that the process is currently in an unworkable state and should be terminated with extreme prejudice. The kernel basically just stops the process and removes it from the process table. The process never even knows what hit it.
The same thing applies to SIGSEGV, but for different reasons. Once the process oversteps its bounds, it can’t be trusted and must be terminated.
The only circumstances in which an unstoppable signal may be deferred is if the process is in IO wait, or stuck in kernel space. Then it’s just deferred, and will be dispatched once the process leaves kernel space.
Leave a Reply