PREV_LECNEXT_LEC

What You Will Learn

Prerequisites

You should already be comfortable with fork() and basic process creation on Linux, know how to compile a C program with gcc, and have a terminal on a Linux machine or VM (any recent distribution with kernel 5.x or 6.x works fine — nothing here is kernel-version sensitive at the API level).

How a Process Actually Ends

A Linux process can stop in exactly two ways: it can terminate voluntarily by calling exit() (or by returning from main(), which the C runtime turns into an exit() call anyway), or it can be terminated involuntarily by an unhandled signal. SIGKILL is the special case here — it cannot be caught, blocked, or ignored by any process, which is exactly why it’s the tool of last resort when a process refuses to respond to anything gentler.

Whichever path a process takes, the kernel performs the same cleanup: every thread in the process stops, every open file descriptor is closed, and every page of memory the process owned is released back to the system. The one thing the kernel does not immediately discard is the process’s exit status — and that single detail is the root of the zombie process problem.

Exit Status: What a Process Reports

When a process ends, it leaves behind a small integer describing how it went. If the process exited normally, this is whatever value was passed to exit() (or returned from main()). If it was killed by a signal, the kernel encodes the signal number instead. By long-standing shell convention, 0 means success and any non-zero value signals some kind of failure — this is exactly what lets a shell script chain commands with && and ||.

Zombie Processes: Why They Exist

The parent is expected to collect a child’s exit status using wait() or waitpid(). Until that happens, the kernel can’t fully discard the child’s process table entry — it still needs somewhere to keep that exit status, and it can’t recycle the PID either, otherwise a later wait() call could return the wrong result. A process in this in-between state shows up as Z in ps or top: a zombie process.

In a well-behaved program, zombies are invisible — the parent calls waitpid() almost immediately after being notified via SIGCHLD, so the zombie state lasts microseconds. The problem only appears when a parent never calls wait() at all. Over time, zombies accumulate, PIDs get exhausted, and the system eventually refuses to create new processes — even though none of the zombies are consuming CPU or memory.

Reaping Children the Right Way

Here is an original demo, ep_reaper.c, that forks a child, lets it exit with a specific status, and shows the parent correctly reaping it with waitpid():

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main(void)
{
    pid_t child_pid;
    int status;

    child_pid = fork();

    if (child_pid == 0) {
        /* child */
        printf("ep_reaper: child running, pid=%d\n", getpid());
        sleep(2);
        exit(7);
    } else if (child_pid > 0) {
        /* parent */
        printf("ep_reaper: parent waiting on pid=%d\n", child_pid);
        waitpid(child_pid, &status, 0);

        if (WIFEXITED(status))
            printf("ep_reaper: child exited normally, status=%d\n",
                   WEXITSTATUS(status));
        else if (WIFSIGNALED(status))
            printf("ep_reaper: child killed by signal %d\n",
                   WTERMSIG(status));
    } else {
        perror("ep_reaper: fork failed");
        exit(1);
    }

    return 0;
}

Build and run it like this:

$ gcc -Wall -o ep_reaper ep_reaper.c
$ ./ep_reaper
ep_reaper: parent waiting on pid=48213
ep_reaper: child running, pid=48213
ep_reaper: child exited normally, status=7

Reaping Asynchronously with SIGCHLD

Blocking on waitpid() is fine for simple tools, but a long-running server that manages many worker processes usually installs a SIGCHLD handler instead, so it can keep doing its main work and reap children only when notified:

#include <signal.h>
#include <sys/wait.h>
#include <stdio.h>

void ep_sigchld_handler(int signo)
{
    int saved_errno = errno;
    pid_t pid;
    int status;

    /* Reap every child that has exited, since one SIGCHLD
       can represent more than one dead child */
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        printf("ep_sigchld_handler: reaped pid %d\n", pid);
    }

    errno = saved_errno;
}

The WNOHANG flag is the key detail: it tells waitpid() to return immediately with 0 if no child has exited yet, instead of blocking the signal handler. Looping on it inside the handler ensures you don’t miss a child if two of them exit close together, since signals of the same type don’t queue.

What Happens to Orphaned Processes

If a parent exits before its child does, the child doesn’t become homeless. The kernel re-parents it, typically to the nearest “subreaper” process or to PID 1 (init / systemd), whose whole job includes calling wait() on processes it inherits this way. This is precisely how daemonizing works, and it’s the mechanism that keeps orphaned children from turning into permanent zombies even when their original parent is long gone.

Common Mistakes and Troubleshooting

Best Practices

• Always reap children — either synchronously with waitpid() or asynchronously via SIGCHLD.
• Prefer WNOHANG loops in signal handlers over a single blocking wait() call.
• Use _exit() instead of exit() after fork() in the child when you must avoid flushing shared stdio buffers twice.
• Never rely on SIGKILL as a first response — try SIGTERM first so the process can clean up.

Performance consideration: reaping is cheap (a syscall per child), but a huge backlog of unreaped zombies does consume kernel memory for their task_struct entries and can eventually exhaust the PID space, so treat unreaped zombies as a leak, not a cosmetic issue.

Security consideration: a process that never reaps its children is a viable local denial-of-service vector — an attacker who can spawn many short-lived children through your service can exhaust PIDs. Always cap concurrent child processes and reap eagerly.

Real-World Use Cases

Web servers running a process-per-request model, shell implementations executing pipelines, container runtimes tracking containerized processes, and init systems like systemd all depend on correct process termination handling. Any long-running supervisor process is, at its core, a specialized reaper.

Summary and Key Takeaways

• A process ends via exit() or an unhandled signal — SIGKILL can never be blocked.
• The exit status is preserved until a parent calls wait() or waitpid().
• An unreaped child is a zombie (Z) — harmless briefly, dangerous if it accumulates.
• SIGCHLD plus a WNOHANG loop is the standard pattern for asynchronous reaping.
• Orphaned children get re-parented and are eventually reaped by their new parent.

Conclusion

Process termination in Linux looks trivial on the surface — a process runs, then it stops — but the mechanics underneath (exit status delivery, zombie states, signal-driven reaping, orphan re-parenting) are exactly what keeps a busy Linux system stable under heavy process churn. Master this and the rest of Linux process management, including the exec() family and daemonization covered in the next lectures of this free embedded Linux course, will make a lot more sense.

Frequently Asked Questions

PREV_LECNEXT_LEC