Process Termination and Resource Cleanup

Core Idea

Processes terminate via exit() system call or signal delivery. The OS transitions the process to zombie state until the parent reaps it via waitpid(). Resource cleanup includes freeing memory, closing file descriptors, and notifying child processes. Proper cleanup prevents resource leaks and zombie accumulation.

Common Misconceptions

Calling exit() immediately frees all resources (some remain in zombie state until reaped). Orphan processes are killed (they are reparented to init/systemd, not killed).

Explainer

You already know that fork() creates a new process and exec() replaces its image with a new program. Termination is the other half of the process lifecycle — the part where the operating system reclaims everything a process was using. A process can terminate in two ways: it calls exit() voluntarily (either explicitly or by returning from main), or it receives a signal that forces it to stop, such as SIGKILL or SIGSEGV. In both cases, the kernel begins an orderly teardown of the process's resources.

During cleanup, the OS closes all open file descriptors, releases allocated memory pages back to the free pool, detaches from any shared memory segments, and removes the process from the scheduling queue. However, the process does not fully disappear at this point. Instead, it enters a zombie state — a minimal entry in the process table that holds the exit status code but consumes no CPU or memory. The zombie exists for one reason: the parent process needs to collect the child's exit status. Think of it like a receipt left on a counter — the work is done, but someone needs to pick up the receipt before the counter space is freed.

The parent collects this exit status by calling waitpid() (or the simpler wait()). Once the parent reaps the zombie, the process table entry is finally removed. If the parent never calls waitpid(), zombies accumulate and eventually exhaust the process table — a subtle resource leak that does not consume memory or CPU but prevents new processes from being created. This is why long-running server processes must always reap their children, typically by calling waitpid() in a loop or by handling the SIGCHLD signal.

A natural question arises: what happens if the parent terminates before the child? The child becomes an orphan process, and the kernel reparents it to the init process (PID 1) or systemd. This is not a failure — init automatically reaps orphans when they terminate, preventing zombie accumulation. The system is designed so that every process always has a parent willing to collect its exit status. Understanding this parent-child cleanup contract is essential for writing reliable systems software, especially daemons and servers that spawn many child processes over their lifetime.