How does Linux "kill" a process?

Question

It often baffles me that, although I have been working professionally with computers for several decades and Linux for a decade, I actually treat most of the OS' functionality as a black box, not unlike magic.

Today I thought about the kill command, and while I use it multiple times per day (both in its "normal" and -9 flavor) I must admit that I have absolutely no idea how it works behind the scenes.

From my viewpoint, if a running process is "hung", I call kill on its PID, and then it suddenly isn't running anymore. Magic!

What really happens there? Manpages talk about "signals" but surely that's just an abstraction. Sending kill -9 to a process doesn't require the process' cooperation (like handling a signal), it just kills it off.

• How does Linux stop the process from continuing to take up CPU time?
• Is it removed from scheduling?
• Does it disconnect the process from its open file handles?
• How is the process' virtual memory released?
• Is there something like a global table in memory, where Linux keeps references to all resources taken up by a process, and when I "kill" a process, Linux simply goes through that table and frees the resources one by one?

I'd really like to know all that!

Answer 1

Sending kill -9 to a process doesn't require the process' cooperation (like handling a signal), it just kills it off.

You're presuming that because some signals can be caught and ignored they all involve cooperation. But as per man 2 signal, "the signals SIGKILL and SIGSTOP cannot be caught or ignored". SIGTERM can be caught, which is why plain kill is not always effective – generally this means something in the process's handler has gone awry.¹

If a process doesn't (or can't) define a handler for a given signal, the kernel performs a default action. In the case of SIGTERM and SIGKILL, this is to terminate the process (unless its PID is 1; the kernel will not terminate init)² meaning its file handles are closed, its memory returned to the system pool, its parent receives SIGCHILD, its orphan children are inherited by init, etc., just as if it had called exit (see man 2 exit). The process no longer exists – unless it ends up as a zombie, in which case it is still listed in the kernel's process table with some information; that happens when its parent does not wait and deal with this information properly. However, zombie processes no longer have any memory allocated to them and hence cannot continue to execute.

Is there something like a global table in memory where Linux keeps references to all resources taken up by a process and when I "kill" a process Linux simply goes through that table and frees the resources one by one?

I think that's accurate enough. Physical memory is tracked by page (one page usually equalling a 4 KB chunk) and those pages are taken from and returned to a global pool. It's a little more complicated in that some freed pages are cached in case the data they contain is required again (that is, data which was read from a still existing file).

Manpages talk about "signals" but surely that's just an abstraction.

Sure, all signals are an abstraction. They're conceptual, just like "processes". I'm playing semantics a bit, but if you mean SIGKILL is qualitatively different than SIGTERM, then yes and no. Yes in the sense that it can't be caught, but no in the sense that they are both signals. By analogy, an apple is not an orange but apples and oranges are, according to a preconceived definition, both fruit. SIGKILL seems more abstract since you can't catch it, but it is still a signal. Here's an example of SIGTERM handling, I'm sure you've seen these before:

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <string.h>

void sighandler (int signum, siginfo_t *info, void *context) {
    fprintf (
        stderr,
        "Received %d from pid %u, uid %u.\n",
        info->si_signo,
        info->si_pid,
        info->si_uid
    );
}

int main (void) {
    struct sigaction sa;
    memset(&sa, 0, sizeof(sa));
    sa.sa_sigaction = sighandler;
    sa.sa_flags = SA_SIGINFO;
    sigaction(SIGTERM, &sa, NULL);
    while (1) sleep(10);
    return 0;
}

This process will just sleep forever. You can run it in a terminal and send it SIGTERM with kill. It spits out stuff like:

Received 15 from pid 25331, uid 1066.

1066 is my UID. The PID will be that of the shell from which kill is executed, or the PID of kill if you fork it (kill 25309 & echo $?).

Again, there's no point in setting a handler for SIGKILL because it won't work.³ If I kill -9 25309 the process will terminate. But that's still a signal; the kernel has the information about who sent the signal, what kind of signal it is, etc.

---

^{1. If you haven't looked at the list of possible signals, see kill -l.}

^{2. Another exception, as Tim Post mentions below, applies to processes in uninterruptible sleep. These can't be woken up until the underlying issue is resolved, and so have ALL signals (including SIGKILL) deferred for the duration. A process can't create that situation on purpose, however.}

^{3. This doesn't mean using kill -9 is a better thing to do in practice. My example handler is a bad one in the sense that it doesn't lead to exit(). The real purpose of a SIGTERM handler is to give the process a chance to do things like clean up temporary files, then exit voluntarily. If you use kill -9, it doesn't get this chance, so only do that if the "exit voluntarily" part seems to have failed.}

Answer 2

Each process runs for scheduled time and then is interrupted by hardware timer, to give its CPU core for other tasks. This is why it is possible to have much more processes than there are CPU cores, or even run all operating system with lots of processes on one single core CPU.

After the process is interrupted, the control returns to the kernel code. That code can then make a decision not to resume the execution of the interrupted process, without any cooperation from the process side. kill -9 may end up execution in any line of your program.

Answer 3

Here's an idealized description of how killing a process works. In practice, any Unix variant will have many additional complications and optimizations.

The kernel has a data structure for each process that stores information about what memory it's mapping, what threads it has and when they are scheduled, what files it has open, etc. If the kernel decides to kill a process, it makes a note in the process's data structure (and perhaps in the data structure of each of the threads) that the process is to be killed.

If one of the process's threads is currently scheduled on another CPU, the kernel might trigger an interrupt on that other CPU to get that thread to stop executing more quickly.

When the scheduler notices that a thread is in a process that must be killed, it won't schedule it anymore.

When none of the process's threads are scheduled any more, the kernel starts freeing the resources of the process (memory, file descriptors, …). Each time the kernel frees a resource, it checks whether its owner still has live resources. Once the process has no more live resource (memory mapping, open file descriptor, …), the data structure for the process itself can be freed and the corresponding entry can be removed from the process table.

Some resources can be freed immediately (e.g. deallocating memory that isn't in use by an I/O operation). Other resources must wait, for example data that describes an I/O operation can't be freed while the I/O operation is in progress (while a DMA in progress, the memory that it's accessing is in use, and cancelling the DMA requires contacting the peripheral). The driver for such a resource is notified, and may try to hurry up the cancellation; once the operation is no longer in progress, the driver will complete the freeing of that resource.

(The entry in the process table is actually a resource that belongs to the parent process, which gets freed when the process dies and the parent acknowledges the event.)