How does the parent process handle the exit status of a child process in UNIX

Every time you run a command in a shell and the shell tells you it succeeded or failed, or a build script decides whether to continue based on whether the previous step “worked,” there’s a specific UNIX mechanism making that possible: the parent process retrieving the exit status of its child. It’s a small piece of machinery, but it’s foundational to how UNIX process control, shell scripting, and even service supervision all work. I want to go through exactly how this works, from the system call level up to shell-visible behavior.

The Basic Model: fork, exec, exit, wait

UNIX process creation follows a well-established pattern. A process calls fork() to create a nearly identical copy of itself (the child), the child typically calls one of the exec() family of functions to replace its memory image with a new program, and eventually the child terminates by calling exit() (or being killed by a signal). The parent, at some point, calls wait() or waitpid() to retrieve information about how the child ended.

Parent Process
    |
    fork() ---------------> Child Process
    |                            |
    |                          exec("/bin/ls")
    |                            |
    |                          ... runs ...
    |                            |
    |                          exit(0)
    |                            |
    wait() <-------------- (kernel holds exit status until collected)
    |
   retrieves exit status

What Happens When a Child Exits

When a child process calls exit(status) (or returns from main(), which implicitly calls exit() with the return value), the kernel doesn’t immediately remove all traces of that process. Instead, it:

1. Releases the process’s memory, open file descriptors, and most other resources back to the system.
2. Converts the process into a zombie — a minimal kernel-level record containing the process ID, the exit status, and some resource usage statistics (CPU time consumed, etc.).
3. Sends a SIGCHLD signal to the parent process, notifying it that a child has changed state (exited, or in some cases stopped/continued if job control signals are being tracked).
4. Waits for the parent to call wait() or waitpid() to retrieve that information, at which point the zombie’s table entry is finally removed entirely.

This design exists because the kernel can’t assume in advance whether the parent cares about the exit status — so it holds onto that minimal record rather than discarding potentially important information.

The wait() and waitpid() System Calls

The wait() system call is the simplest form — it blocks the calling process until any one of its children terminates, then returns that child’s PID and stores its exit status in the provided integer pointer.

#include <sys/wait.h>

pid_t pid = fork();
if (pid == 0) {
    // child
    exit(42);
} else {
    int status;
    pid_t child_pid = wait(&status);
    // status now encodes how child_pid exited
}

waitpid() is a more flexible version that lets you wait on a specific child PID, or use flags like WNOHANG to avoid blocking if no child has exited yet:

pid_t result = waitpid(pid, &status, WNOHANG);
if (result == 0) {
    // child hasn't exited yet, keep doing other work
} else if (result == pid) {
    // child has exited, status is populated
}

Decoding the Exit Status

The status value returned by wait()/waitpid() isn’t a plain integer you can read directly — it’s a packed bitfield that encodes multiple pieces of information: whether the process exited normally or was killed by a signal, the actual exit code, or the signal number that killed it. POSIX defines a set of macros specifically for decoding this safely:

• WIFEXITED(status) — true if the child terminated normally, via exit() or returning from main().
• WEXITSTATUS(status) — if WIFEXITED is true, extracts the actual exit code (0-255) the child passed to exit().
• WIFSIGNALED(status) — true if the child was terminated by an unhandled signal (like SIGSEGV or SIGKILL).
• WTERMSIG(status) — if WIFSIGNALED is true, extracts which signal caused the termination.
• WIFSTOPPED(status) / WSTOPSIG(status) — relevant for job control, when a child has been stopped (not terminated) by a signal like SIGSTOP.

if (WIFEXITED(status)) {
    printf("Child exited normally with code %d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
    printf("Child was killed by signal %d\n", WTERMSIG(status));
}

Why Exit Codes Matter

By UNIX convention, an exit code of 0 means success, and any non-zero value indicates some kind of failure or specific error condition, with the exact meaning of non-zero codes defined by whatever program is being run. This convention is what makes shell scripting and process chaining work:

if command1; then
    echo "command1 succeeded"
else
    echo "command1 failed with exit code $?"
fi

The $? shell variable holds the exit code of the most recently completed foreground command, which the shell itself obtains via the same wait()/waitpid() mechanism under the hood — the shell is, itself, just another parent process managing child processes.

Chained operators like && and || in shell scripts also rely directly on this: command1 && command2 only runs command2 if command1‘s exit status was 0.

Handling SIGCHLD Asynchronously

For long-running programs (servers, supervisors, shells with job control) that don’t want to block on wait() while other work needs to continue, the standard approach is to install a signal handler for SIGCHLD and call waitpid() with WNOHANG inside that handler, looping until there are no more terminated children to reap:

void sigchld_handler(int sig) {
    int status;
    pid_t pid;
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        if (WIFEXITED(status)) {
            log_message("Child %d exited with code %d", pid, WEXITSTATUS(status));
        }
    }
}

int main() {
    signal(SIGCHLD, sigchld_handler);
    // continue with other work; children are reaped asynchronously
}

This pattern is exactly what process supervisors like systemd, supervisord, and shells with job control use internally to track multiple background jobs simultaneously without blocking.

What Happens If the Parent Never Retrieves the Exit Status

If the parent never calls wait()/waitpid(), the child remains in the zombie state indefinitely, occupying a slot in the kernel’s process table. This is the exact mechanism behind zombie process accumulation, which I cover in more depth in companion articles on preventing and managing zombies. If the parent itself terminates before reaping its children, those children (including any that are already zombies) get re-parented to init (PID 1) or a designated subreaper, which is specifically designed to reap orphaned processes promptly.

Real-World Example: How a Shell Handles This

When you run ls | grep foo in bash, the shell forks two child processes (one for ls, one for grep), connects them with a pipe, and then waits for both to complete, tracking each one’s exit status separately. The overall exit status reported for the pipeline ($?) is, by default, the exit status of the last command in the pipeline, though bash’s pipefail option can change this behavior to report failure if any command in the pipeline fails — a subtlety that trips up a lot of shell scripters until they hit a bug caused by an early pipeline command failing silently.

How Different Languages Expose This

• C/C++ — direct access via wait()/waitpid() and the WIF*/W* macros, as shown above.
• Python — the subprocess module exposes this through Popen.returncode after calling .wait() or .communicate(), abstracting away the raw bitfield decoding.
• Node.js — the child_process module’s 'exit' event handler receives both code and signal parameters separately, mirroring the WIFEXITED/WIFSIGNALED distinction.
• Go — exec.Cmd.Wait() returns an error that can be inspected via ExitError.ExitCode() to get the numeric exit status.

Best Practices

• Always check exit status rather than assuming a command succeeded, particularly in scripts that chain multiple operations together.
• Use WIFEXITED/WIFSIGNALED macros (or their language-level equivalents) rather than trying to interpret the raw status value directly, since the bit-packing format isn’t something application code should depend on.
• In long-running processes managing multiple children, use SIGCHLD handling with WNOHANG rather than blocking wait() calls, to keep the process responsive.
• Be deliberate about pipefail-style settings in shell scripts if pipeline failures matter to your logic.
• Log both the exit code and any relevant context when a child process fails, to make debugging production issues far easier.

Exit Status Propagation in Process Chains

One subtlety worth understanding in depth is how exit status behaves across more complex process relationships than a simple single parent-child pair.

Pipelines

As mentioned, a pipeline like cmd1 | cmd2 | cmd3 forks a separate process for each command, and the shell tracks each one’s exit status independently. By default, only the last command’s exit status becomes $?, which means a failure earlier in the pipeline can go completely unnoticed unless you explicitly check for it:

false | true
echo $?   # prints 0, even though "false" failed, because "true" (the last command) succeeded

Bash’s PIPESTATUS array gives you access to every command’s individual exit status in the most recently executed pipeline:

false | true
echo "${PIPESTATUS[0]} ${PIPESTATUS[1]}"   # prints "1 0"

And the set -o pipefail option changes the overall pipeline exit status to reflect the first non-zero exit code among all commands in the pipeline, which is a much safer default for scripts where any stage failing should be treated as an overall failure.

Subshells and Command Substitution

When you use command substitution ($(command)), the exit status of the substituted command is available via $? immediately after the substitution completes, following the same wait/exit-status mechanics as any other child process, just wrapped in slightly different shell syntax.

Process Groups and Job Control

In interactive shells, background jobs (command &) are tracked as separate jobs, each with their own PID, and the shell’s built-in jobs and wait commands let you query or block on specific jobs by job number rather than raw PID, which is more convenient for interactive use. Internally, this is still built on the same waitpid() mechanism, just with a friendlier interface layered on top by the shell itself.

Common Pitfalls Around Exit Status Handling

Forgetting that $? only reflects the most recent command — if you run several commands and then check $?, you’re only getting the last one’s status; anything you needed to check from earlier commands must be captured immediately after each one runs, before the next command overwrites $?.

Assuming a non-zero exit code always means “the same kind of failure” — different programs use different non-zero codes to mean different things (a common convention reserves specific ranges for specific error categories), so treating “any non-zero” as a single generic failure case can lose useful diagnostic information that a more careful script could have surfaced.

Not handling the case where a child is killed by a signal versus exiting normally with a non-zero code — these are meaningfully different situations (a deliberate error exit versus a crash or external termination), and code that only checks WEXITSTATUS without first checking WIFEXITED can silently misinterpret a signal-based termination as if it were a normal exit with a garbage status value.

Race conditions in signal-handler-based reaping — as covered in the companion article on zombie process circumstances, a SIGCHLD handler that doesn’t loop with WNOHANG can miss additional children that exited around the same time, since SIGCHLD delivery isn’t guaranteed to happen once per child if multiple children exit in quick succession.

Exit Status in Process Supervision Software

Production process supervisors (systemd, supervisord, PM2 for Node.js applications, and similar tools) build fairly sophisticated logic on top of this basic exit-status mechanism — for example, distinguishing between a clean shutdown (exit code 0), a crash (non-zero exit code or signal termination), and using that distinction to decide whether to automatically restart the service, how long to wait before restarting (often with exponential backoff), and whether to alert an operator after repeated failures. Understanding the underlying wait()/exit-status mechanics makes it much easier to reason about why a supervisor is behaving a certain way — for instance, why it considers a service “flapping” and stops trying to restart it after a certain number of rapid failures.

Exit Status Conventions Across Common Tools

Beyond the general 0-for-success convention, many widely used command-line tools follow more specific, documented exit code schemes that scripts can rely on for finer-grained decision making rather than treating every non-zero result identically. grep, for instance, returns 0 if a match was found, 1 if no match was found (which isn’t necessarily an “error” in the everyday sense, just a negative result), and 2 if an actual error occurred, such as being given a nonexistent file to search — a script that treats exit codes 1 and 2 identically would fail to distinguish “nothing matched” from “something actually went wrong.” Similarly, curl has a well-documented range of exit codes indicating specific failure categories (connection failures, timeout, SSL errors, and so on), and many well-designed command-line tools follow the broader convention, common across UNIX utilities, of reserving specific codes above 128 to indicate the process was terminated by a signal (the convention being 128 plus the signal number), letting a careful script distinguish a deliberate non-zero exit from an external termination even without directly inspecting WIFSIGNALED. Knowing that these conventions exist — and checking a tool’s documentation for its specific exit code meanings rather than assuming a generic pass/fail — is a genuinely useful habit for anyone writing production shell scripts or automation that needs to react intelligently to failure.

Summary

When a child process terminates in UNIX, the kernel preserves its exit status in a minimal zombie record until the parent process retrieves it via wait() or waitpid(). That exit status is a packed value decoded with macros like WIFEXITED and WEXITSTATUS, distinguishing between normal termination with an exit code and termination by an unhandled signal. This mechanism underpins everything from simple shell exit-code checks ($?) to sophisticated process supervisors that asynchronously reap many children via SIGCHLD handlers — and neglecting it entirely is precisely what causes zombie processes to accumulate.

FAQs

What’s the difference between wait() and waitpid()? wait() blocks until any child terminates and only works with a single child at a time in a simple way; waitpid() lets you target a specific child PID, use non-blocking flags like WNOHANG, and offers finer control overall.

Can a parent retrieve a child’s exit status more than once? No — once wait()/waitpid() successfully retrieves a child’s status, the kernel removes the zombie entry, and that information is gone; there’s no way to query it again afterward.

What exit status does a process killed by kill -9 produce? WIFEXITED will be false and WIFSIGNALED will be true, with WTERMSIG returning the signal number for SIGKILL (9), since the process didn’t terminate via a normal exit() call.

Why does $? in bash sometimes show a number greater than 255? It typically doesn’t — exit codes are conventionally limited to the 0–255 range because that’s what fits in the lower byte of the status value; values you might see above that are usually the result of specific shell or signal-related encoding conventions, not a literal larger exit code.

Does this exit-status mechanism exist on Windows too? Windows has its own analogous concept — process exit codes retrievable via GetExitCodeProcess() — but the underlying mechanics (zombie states, SIGCHLD, wait()) are specific to the UNIX process model and don’t map directly onto how Windows manages process lifecycles.

References

• POSIX.1-2017 — wait(), waitpid(), exit() specification
• Linux man-pages — wait(2), wait(3type), signal(7)
• Stevens & Rago — Advanced Programming in the UNIX Environment, Process Control chapter
• Bash Reference Manual — “Exit Status” and “The Set Builtin” (pipefail)
• Python documentation — subprocess module