Technology · PRACTICAL GUIDE
Linux shows a defunct zombie process? Prove the parent and wait boundary before killing anything
A zombie is already dead; the living parent, subreaper or container PID 1 owns cleanup. Bind child and parent identity, then repair one safe reaping boundary.
A zombie or defunct process is not a running task that can be killed again. It is a terminated child whose status is still held so a living parent or reaper can collect it. The safe investigation therefore begins with parent identity, not a stronger signal.
Freeze the child PID and start time, the parent PID and start time, the service or container boundary and the Z-count trend. Then repair the one process that owns waiting and prove bounded reaping through the original launcher.
1. Freeze the record before restarting the parent
Capture the exact ps output, child PID, parent PID, command names, user, container or unit, first observation time and count of Z-state entries. Read /proc/CHILD/stat and /proc/PARENT/stat while both paths exist; preserve each start-time field so a later reused PID is not mistaken for the original process.
Do not begin with kill -9 CHILD. The child has already terminated, so there is no running instruction stream to stop. Do not run a bulk command against every parent either: it can terminate unrelated services before you have identified ownership or rollback.
2. Prove the living parent and wait boundary
Confirm state Z and PPID from the same namespace view, then map the parent to its executable, start time, service, supervisor and deployment. A zombie remains because the responsible parent or subreaper has not collected the termination status with wait, waitpid or waitid.
Check whether the parent is healthy, stuck, overloaded, misconfigured or simply between collection cycles. One transient zombie can be normal for a very short interval; a stable or rising count under comparable workload is evidence of a reaping defect.
3. Account for PID namespaces and subreapers
Inside a container, PID 1 may be the application or a minimal init, not the host init process. Record the namespace-local tree and the host-side container identity. Docker documents that --init installs an init process whose responsibilities include reaping zombies.
Do not assume adding an init flag repairs application code. It can correctly reap orphaned descendants, but a long-lived parent that retains its own terminated children still needs a correct wait loop. A subreaper changes which living ancestor receives adopted descendants; preserve that boundary in the incident record.
4. Choose the smallest parent-safe repair
If you own the program, fix child lifecycle handling: collect every terminated child, handle bursts, avoid a handler that loses notifications, and cover normal exits plus error paths. Test with the same concurrency and failure timing that created the Z entries.
For third-party software, prefer a documented service restart or upgrade after saving evidence. For a container whose PID 1 does not reap adopted children, use the runtime or orchestrator init mechanism after change review. Terminate a parent only when its service impact, dependencies, rollback and restart path are understood.
5. Verify bounded reaping through the original launcher
Run the same workload through the same systemd unit, container command, supervisor or shell wrapper. Sample parent identity, Z-state count and child-completion count over a fixed interval. A one-time empty ps listing after restart is not enough.
Accept the repair only when the parent remains healthy, terminated children are collected, the zombie count returns to a bounded baseline, and no unrelated process is disrupted. Preserve the before-and-after ledger and stop if PID identity, namespace ownership or rollback remains uncertain.
