Linux processes and PIDs

What it means

A PID is the number used to identify a process. The parent–child relationship identifies which process created the child; it is separate from whether the child is still executing.

Here, reaping means collecting an exited child's termination status. Keeping execution and collection separate explains how a process can stop doing application work while a record of its exit remains.

Try it

Simulation: start with Child state = running and Parent collected status? = no. Change only Child state to exited, then select Compare with baseline to compare the results. After inspecting that contrast, keep exited selected and change Parent collected status? to yes to examine reaping. These are local teaching inputs; no real process is inspected or changed.

The initial result is Running child: “Exit status cannot be collected before this child has exited.” The no input means status has not been collected; it is not, on its own, evidence of a zombie.

For the baseline-to-exit comparison, keep Parent collected status? = no. To isolate collection, manually observe exited/no and then exited/yes, keeping Child state = exited. Compare with baseline always uses running/no, even when the current state is exited/yes; it does not save exited/no as a new reference. Changing either input clears the displayed comparison. The manual before-and-after contrast and the fixed-baseline button answer different comparison questions.

Reset restores Child state to running and Parent collected status? to no, removes input errors and clears the comparison. It does not change which FAQ answers or the About this model panel you have opened or closed. There is no running clock or event history to reset.

How it works

In a typical fork/exec sequence, a successful fork creates a child with a distinct PID. Parent and child continue from the call, with different return values identifying their roles. If fork fails, no child is created.

The child can keep executing that program or use execve to replace it. A successful execve runs the replacement program in the same process: the PID stays the same. The interactive starts with an existing child; it does not simulate creation or program replacement.

In the ordinary case modeled here, exit and reaping are separate events. Exit ends the child's execution, but the kernel retains termination information so the parent can learn how the child finished. That retained, uncollected state is the zombie state.

When the parent collects the retained termination status through a wait interface, it reaps the child and removes the zombie state. Collection is therefore an accounting transition after execution has ended, not another way of stopping a running workload.

Both inputs matter. Parent collected status? = no describes the absence of collection, but it does not by itself establish a zombie: a running child also has no collected termination status. Only the combination of exit and retained, uncollected status supports that result under the stated assumptions.

Worked example

This is a synthetic baseline, not a captured process listing.

The result is Running child. There is no termination status to collect yet, so the absence of collection is expected. This is the important intermediate condition: an uncollected status cannot be treated as a retained exit record until the child has actually exited.

What changes when the condition changes

Change Child state to exited while keeping Parent collected status? at no. The result becomes Exited; zombie status retained: “The child has exited but its termination status remains until reaped.” The missing condition in the baseline was exit—not simply the absence of collection.

Now keep Child state at exited and change Parent collected status? to yes. The result becomes Reaped; no zombie entry: “Collecting the exit status removes the zombie state.” This second contrast shows why exit does not imply a permanently retained entry. Collection changes the bookkeeping; it does not restart the child.

In practice

On a Linux host you are authorized to inspect, begin with a read-only observation of the one child process and its recorded parent. Read PID, state, parent and start information together, and record the observation time and host/boot context. For example, /proc/PID/stat reports a process start time relative to system boot. PIDs can be reused, so an old number alone is not reliable current identity evidence. Comparing this information is a diagnostic cross-check, not a race-free guarantee about a later action.

If the child is reported as a zombie, the expected interpretation is that execution has ended while termination information remains. The next question concerns collection by the parent; the listing alone does not explain why collection has not occurred. If the child is still running, the zombie explanation does not apply.

STOP before any intervention if the current identity, parent relationship or your authority is uncertain. Repeatedly signaling an already exited child does not address status collection. This page provides no termination, parent-restart or service-change procedure; those actions need a separately justified plan, impact assessment, verification and rollback.

Limits and unknowns

The simulation assumes ordinary retained child-exit status. It does not model explicitly ignored SIGCHLD, SA_NOCLDWAIT, reparenting, threads or namespaces. Its two Child state choices also do not reproduce scheduling behavior or explain every state shown by a process-inspection tool.

Child state = running together with Parent collected status? = yes is invalid: a running child cannot already have had its termination status collected. The interface shows an input error rather than a calculated outcome, and comparison is unavailable until you correct the combination or use Reset. It does not silently treat that combination as a reaped child.

A valid result establishes only what follows from your selected synthetic inputs. The simulation cannot determine the actual state of a process, its parent's wait behavior or your permissions on a real host. Without those observations, the real-machine explanation remains unknown. With JavaScript disabled, the initial example and article remain readable, but the interactive controls are unavailable.

What to carry forward

A zombie entry is evidence of ended execution with retained termination status, not continuing application work. Use that distinction to investigate status collection by the parent, while keeping process identity and permissions separate from any decision to intervene. The retained entry alone does not establish a parent defect or justify restarting a service.