This question already has an answer here:

If a program is not allowed to handle or ignore SIGKILL and SIGSTOP, and must immediately terminate, why does the kernel even send the signal to the program? Can't the kernel simply evict the program from the CPU and memory? I assume the kernel would have the ability do directly do this.

marked as duplicate by Sergiy Kolodyazhnyy, Stephen Harris, l0b0, Community Dec 14 '18 at 3:42

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


This answer is partly correct, there is more to do to terminate a process than to free the memory. However a SIGKILL is not a tap on the shoulder and a request to do something, it is one of the few signals that a process can't ignore or handle. That means that a SIGKILL is always handled by the kernel's default handler, and this default action, as with most of the signals, is to terminate the process receiving the signal. The user space part of the program won't even see the signal, so there is no request to do something, no cooperation required, and therefor a program can't misbehave upon receiving SIGKILL, whether by malicious intent or by some programming error. Instead the kernel side of the process will handle the signal and terminate the process. So in a way the kernel is directly terminating the process, by telling another part of the kernel that the process shall be terminated.

From a programming point of view, when the kernel wants to kill a program (which mostly happens because of missing resources, especially not enough free RAM), there are two possibilities, to duplicate the code that does this when a process has to be terminated, or just call a single function to deliver the signal and know that everything necessary to terminate the process will be handled. The second approach is not only less initial work, it means much less work in the long run because the duplicate code doesn't have to be maintained.


The user-space part of a process terminated by SIGKILL never gets to know about it; the kernel deals with everything. (This does mean that some resources can leak: temporary files, shared memory allocations, resources held on behalf of the killed process by another process such as an X server…)

However the signal still needs to be delivered, so that other processes can find out how the killed process was terminated. A parent, using wait, will get the information that the killed process was terminated by SIGKILL.

  • 1
    You said that some resources can leak. How can that happen? Doesn't the kernel keep careful track of all resources currently used by a process? – 1026501 Dec 13 '18 at 22:41
  • 3
    @1026501 Certain types of resources, like temporary files or SysV shared memory, cannot be cleaned up automatically by the kernel. If the process doesn't get a chance to remove them itself, they'll be left in place on SIGKILL. – duskwuff Dec 13 '18 at 23:04
  • 4
    Similarly, a program might own higher-level resources that the kernel does not know about. For example, an application might own an uncommitted database transaction. Eventually, the database server will give up and roll it back (probably shortly after the TCP connection times out), but until that happens, it occupies resources and may even prevent the database server from processing other transactions because of write locks. – Kevin Dec 14 '18 at 0:43
  • A program terminated by SIGKILL never gets to know about it. But processes are like upside-down icebergs: the program resides in the 90% that you can see above the water line (in userland), but the 10% that's in kernel space is part of the process, too. – G-Man Dec 14 '18 at 4:04
  • Thanks @G-Man, I’ve clarified my answer in that regard. – Stephen Kitt Dec 14 '18 at 4:46

An overview of how signals work, in order to complete the other answers which are very good:

The execution of a process can happen in two modes: in userspace or in kernelspace. When in userspace, the process executes the code of its program whereas in kernelspace, it executes the code of the kernel. Processes run in userspace as much as possible to do their work but enter kernelspace from time to time during their execution when they make a system call (which is necessary for any privileged operation on the hardware or shared resources of the system itself, like reading a file) or when they are interrupted in their execution.

They are two cases in which a signal is handled: when a process returns into userspace after having finished a system call, or when it wakes up from an interruptible sleep and resumes its execution. In both cases, the process is in kernelspace. Before anything else, the kernel checks if some signal is pending for the process and acts upon it. If a handler is defined for the signal for example, it makes the process execute it upon its return into userspace. As you've said yourself, the case of KILL is special because it cannot be captured. So, it's actually a simple case for the kernel: the return to userspace is cancelled and the process is killed right away, which means that it won't execute any code in userspace anymore, its memory is freed, its parent process is notified of its death, etc.

  • Thank you for writing this; now I don't have to.    :-)    Processes are like upside-down icebergs: you can easily see the 90% that's above the surface (in userland), but the 10% that's in kernel space is part of the process, too.  I disagree slightly with something you said: "the process is killed right away, [and then] its resources [are] freed, etc."  I would say that the actual, final death of the process doesn't occur until at least when the exit() routine returns control to the scheduler; arguably, not until the parent reaps the status and the proc table entry is freed. – G-Man Dec 14 '18 at 4:04
  • @G-Man Hmm, I see what you mean, I've oversimplified that part. It's quite philosophical in a way: are you dead when you cease to be conscious of being alive or when others do? :p – lgeorget Dec 14 '18 at 9:18
  • Wow; I didn't intend for this to get all Philosophical and Metaphysical!    :-)    ⁠ – G-Man Dec 14 '18 at 9:31

Processes on exit perform several cleanup actions like freeing memory, releasing semaphores, closing files, mayhap some statistics, within their process context / environment. Although the kernel could replicate that, it's easier to tap the process on its shoulder and ask it to commit suicide.

  • 5
    I’m curious to learn how a process can do anything at all in response to SIGKILL, unless the kernel is acting on its behalf. – Stephen Kitt Dec 13 '18 at 19:37
  • 2
    You are wrong. Processes do not receive a SIGKILL: unix.stackexchange.com/questions/485644/… – What Dec 13 '18 at 21:08
  • But couldn't a process be so stuck that it cannot even do these actions? Wouldn't a malicious process somehow be able to misbehave and not terminate? It would make much more sense for the kernel to just stop giving the process CPU time as indicated in the link given by @What. – 1026501 Dec 13 '18 at 21:42
  • @1026501 That is exactly what happens. This response is incorrect. – duskwuff Dec 13 '18 at 23:01
  • @RudiC Wrong!!! – Greg Schmit Dec 13 '18 at 23:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.