Two ways a process ends
In the previous guide you watched a process be born: a parent calls fork to clone itself, the child calls exec to load a new program, and the whole machine grows one more leaf on its process tree. Birth, it turns out, is the cheerful part. Ending a process well is fussier than it looks, and getting it wrong leaves behind little messes the kernel has to clean up. So let us follow a process all the way to its last breath.
A process can stop running in two broad ways. The tidy way is voluntary: it reaches the end of its work and calls exit, handing back a small integer called an exit status — 0 by long convention means success, anything else signals some kind of failure. The blunt way is involuntary: the kernel kills it from outside, perhaps because it tried an illegal memory access, or because another process sent it a terminating signal (the everyday `kill` command does exactly this). Either way, the act of finishing is captured by process termination, and either way the kernel's first job is the same: reclaim the resources.
What gets reclaimed? The process's whole address space — its text, data, heap, and stack — is unmapped and the physical frames are freed. Open files are closed, locks are released, network connections are torn down. You would think that finishes the job entirely. But there is one thing the kernel cannot throw away yet, and that one leftover is the source of nearly every surprise in this guide.
The leftover: an exit status nobody has read yet
Here is the rule that makes everything else click: a child's exit status belongs to its parent. When a child finishes, the kernel cannot simply forget it, because the parent has a right to ask later, "How did my child do — did it succeed or fail?" The parent asks by calling wait, which blocks until a child finishes and then hands back that small exit-status integer. This collecting of a dead child's status is called reaping, and it is the moment the very last trace of the child is finally swept away.
parent: pid = fork() child: ... do the work ...
if pid > 0: exit(0) # status = 0 (success)
status = wait() |
# <-- child fully gone v
else (pid == 0): [ZOMBIE: dead, but status not yet read]
... be the child ... ^
| parent's wait() reaps it hereSo a finished child is in a strange in-between condition: its memory is gone, but its entry in the kernel's process table must linger, holding just the exit status and PID, until the parent calls wait to collect them. A process in exactly this state — dead but not yet reaped — is a zombie process. The name is grimly apt: it is no longer a living process (it runs no code, owns no memory), yet it has not fully departed either. It is a single line in a table, waiting to be read and released.
When the parent dies first: orphans and PID 1
Now flip the timeline. What if the parent dies while its child is still happily running? The child does not die with it — a running process is not torn down just because its parent left. But it now has a serious problem: when it eventually finishes, who will call wait to reap it? Its parent is gone. A still-running child whose parent has terminated is called an orphan process, and if nothing intervened, every orphan would become an un-reapable zombie forever. Unix solves this with one elegant rule.
When a process dies, the kernel walks through its children and re-parents every orphan onto a special process at the very root of the tree: the init process, which always has process ID 1 and is the first user process started at boot. PID 1 has one humble but vital duty among many: it repeatedly calls wait, so any orphan that lands on it gets reaped the moment it finishes. Think of init as the building manager who quietly adopts every child whose family has moved out, purely so that someone is always there to sign the final paperwork.
An easy way to keep the two straight: a zombie has a living parent that has not yet reaped it, while an orphan has lost its parent and gets adopted by PID 1. A zombie is a status nobody has read; an orphan is a child nobody is watching. They are opposite failures of the same parent-child contract — and once init adopts an orphan, that orphan can never itself become a stuck zombie, because PID 1 is always waiting to reap.
Why processes need to talk — and why it is hard
All this ceremony around birth and death exists because processes are deliberately isolated. Back in the address-space guide you learned that each process gets its own private memory; one process simply cannot reach into another's heap or stack. That isolation is a feature — it stops a buggy program from corrupting its neighbours — but it raises an obvious question: if processes are walled off from each other, how do cooperating programs share work at all? A web browser, a shell pipeline, a database and its clients — all are many processes that must coordinate. The answer is inter-process communication, or IPC: a set of channels the kernel provides so that isolated processes can pass information across their walls on purpose.
IPC mechanisms fall into two big families, and the split is worth internalising. In shared memory, the kernel maps the same physical frames into two processes' address spaces, so they can read and write a common region directly — fast, because after setup the kernel steps out of the way. In message passing, processes never share memory; instead one calls something like send and the other calls receive, and the kernel copies the data across between them. A pipe — the `|` you type between two shell commands — is the everyday face of message passing: the left program's output is copied through the kernel into the right program's input.
Each family trades off the same two things in opposite directions. Shared memory is fast but dangerous: the moment two processes write the same region, you are back in the world of race conditions, and you must guard the shared data with synchronisation — a semaphore or a lock — exactly as you would for threads. Message passing is slower (every message is a copy through the kernel) but safer: with no shared region there is nothing to race over, and it works even when the two processes are on different machines across a network. Neither is simply better; they are different points on a speed-versus-safety dial.
Putting it together: a child that reports back
Let us trace one small, complete story that uses everything in this rung. A parent wants a job done in parallel, so it forks a child, the child runs a computation and writes its result into a shared-memory region, then exits with status 0; the parent waits, reaps the child, and reads the result. Watch how creation, communication, and termination interlock into one clean lifecycle.
- The parent sets up a shared-memory region (so both will see the same frames), then calls fork. Now there are two processes running almost-identical copies, distinguished only by fork's return value: 0 in the child, the child's PID in the parent.
- The child does its computation. When it has an answer, it writes the answer into the shared region — guarded by a semaphore so the parent never reads a half-written value.
- The child calls exit(0). Its memory is freed, but its exit status lingers: for this brief instant it is a zombie, holding one line in the process table.
- The parent, which had been blocked in wait, is woken: it reaps the child (clearing the zombie and learning the status was 0 = success), then reads the finished answer out of the still-mapped shared region.
Notice the order is not accidental. If the parent forgot to wait, the child would stay a zombie. If the parent had exited before the child finished, the child would have been orphaned and adopted by PID 1. And if the two had shared that memory without a semaphore, the parent might have read a value mid-write. Three guides ago a process was a recipe being cooked; you can now see the full meal — many cooks, started on demand, talking through carefully chosen channels, each cleaned up and accounted for when its dish is done.