When a process completes its task, it triggers a sequence of cleanup steps: it sends an exit code to the operating system, the OS reclaims all resources the process was using, and the process entry is removed from the system’s process table. This doesn’t happen instantly. The operating system orchestrates several stages to ensure nothing is left behind, and the process’s parent is properly notified of the outcome.
The Process Signals It’s Done
A process tells the operating system it has finished in one of two ways: by reaching the end of its main function (using a return statement) or by calling an exit function from anywhere in the code. In both cases, the process sends back a single integer called an exit code or exit status. This number is the process’s final message to the outside world.
An exit code of zero means the process finished successfully. A nonzero code means something went wrong. This scheme exists because there’s only one way to succeed but many possible failure modes, so reserving zero for success and leaving all other numbers for different types of errors gives programmers flexibility. Exit codes typically range from 0 to 255. If a process was killed by a signal rather than exiting on its own, the shell usually records the exit code as 128 plus the signal number. A code of 127 means the command wasn’t found at all, and 126 means it was found but couldn’t be executed.
Shell scripts and automation tools rely heavily on these codes. When you chain commands together or write a script that runs several programs in sequence, the exit code from each step determines whether the next step runs or the script halts with an error.
Resource Cleanup and Reclamation
Every running process uses system resources: memory, open files, network connections, CPU time. The operating system is responsible for reclaiming all of these when a process exits, even if the program itself didn’t clean up properly.
The kernel closes all open file descriptors and directory streams the process had open. Any memory pages allocated to the process are freed and returned to the system’s available pool. If the process had multiple threads running, all of those threads are ended and their resources cleaned up as well. CPU registers that were storing the process’s execution state are released.
On Windows, the sequence is more explicitly defined. When a process exits, all threads except the one that initiated the exit are terminated immediately. Then every loaded library (DLL) gets a notification that the process is detaching, giving each library a chance to run its own cleanup code. After that, the calling thread itself is terminated, all object handles the process had open are closed, and the process’s status changes from “still active” to whatever exit code the process returned.
The Parent Process Gets Notified
Processes don’t exist in isolation. Almost every process was created by a parent process, and that parent often needs to know when its child finishes and whether it succeeded. This communication happens through a mechanism called “waiting.”
On Unix-like systems, a parent process can call a wait function that pauses the parent’s execution until one of its child processes exits. When a child finishes, the parent resumes and receives two pieces of information: the child’s process ID and its exit status. This lets the parent decide what to do next based on whether the child succeeded or failed. If the parent has multiple children running, it will resume as soon as any one of them exits.
On Windows, the system uses a signaling mechanism instead. When a process terminates, the state of the process object becomes “signaled,” which wakes up any threads that were waiting for that process to finish. The effect is similar: the parent (or any other process watching) learns that the task is complete and can read the exit code.
Zombie and Orphan Processes
The handoff between a finished child and its parent doesn’t always go smoothly, and two edge cases can arise.
A zombie process happens when a child finishes executing but its parent hasn’t collected the exit status yet. The child’s resources have been freed, but a small entry remains in the system’s process table, holding onto the exit code until the parent retrieves it. The process is technically dead but still takes up a slot. If a program spawns thousands of children and never collects their exit statuses, zombie entries accumulate and can eventually exhaust the process table.
An orphan process is the opposite situation. The parent terminates before the child finishes. The still-running child becomes an orphan. On most Unix-like systems, orphaned processes are automatically adopted by the init process (process ID 1), which takes responsibility for collecting their exit statuses when they eventually finish. Modern service managers like systemd handle this differently depending on configuration. By default, when a main service process exits, systemd kills all remaining child processes in the same group to keep things tidy. This behavior can be changed if you specifically want child processes to outlive their parent.
Removal From the Process Table
The operating system tracks every process through an internal data structure, sometimes called a process control block. This record stores everything the OS needs to manage the process: its current state, memory allocations, open files, scheduling priority, and more. All processes, regardless of their state, live in the system’s process table.
Only upon termination is a process fully eliminated from this table. Once the exit code has been delivered to the parent (or the system has determined no parent is waiting), the kernel removes the process control block entirely. At that point, the process truly ceases to exist. The process ID it was using becomes available for reuse by future processes.
What This Looks Like in Practice
If you’ve ever run a command in a terminal and seen it return you to the prompt, you’ve watched this entire sequence play out in milliseconds. The program finished its work, returned an exit code (you can check it by typing echo $? in a Unix shell), the operating system reclaimed its memory and closed its files, and the shell (the parent process) collected the exit status and decided to print a new prompt because everything went fine.
When things go wrong, the exit code tells the story. A program that crashes from a segmentation fault, for example, gets terminated by a signal, and the shell records a nonzero exit code reflecting that. The cleanup still happens. The OS still reclaims resources. But the nonzero code propagates outward, potentially stopping a script, triggering an error handler, or simply showing you a message that something failed. The process lifecycle ends the same way whether the task succeeded or not. The only difference is the number it leaves behind.