Claude on Question 13, Sep 29

The key thing to understand

A zombie process is already dead. It's not running, not consuming CPU, and holds no memory beyond a small entry in the kernel's process table. That entry exists solely to store the exit status until the parent process calls wait() to collect it.

This is why signals do nothing. SIGTERM, SIGKILL, SIGABRT — none of them work, because there's no running process to deliver a signal to. You're trying to kill something that's already a corpse.

Finding the real culprit

The problem is the parent that isn't reaping its children. Find it:

ps -eo pid,ppid,state,cmd | awk '$3 ~ /^Z/'

Or:

ps aux | grep -w Z

The PPID column is what matters. That's the process with the bug.

Fixing it

1. Ask the parent to reap (least disruptive)

Send SIGCHLD to the parent — some programs have a handler that will trigger a wait():

kill -s SIGCHLD <PPID>

This often does nothing, because a parent that leaks zombies usually isn't handling SIGCHLD properly in the first place. But it's free to try.

2. Kill or restart the parent

When a parent dies, its children are reparented to PID 1 (init/systemd), which reaps zombies unconditionally. So:

kill <PPID>          # try graceful first
kill -9 <PPID>       # if it won't budge

If it's a service, prefer the proper restart:

sudo systemctl restart <service>

The zombies will vanish within milliseconds of the parent exiting.

3. Do nothing

Genuinely a valid answer. A handful of zombies is harmless. They only matter if:

• •The count keeps climbing (you'll eventually exhaust kernel.pid_max and be unable to fork anything — check sysctl kernel.pid_max, typically 32768 or 4194304 on newer kernels)
• •They're holding PIDs you need

Check your current count:

ps -eo state | grep -c Z

If that number is stable at 3, ignore it. If it's growing, you have a leak worth fixing.

What if the parent is PID 1?

If PPID is 1 and the zombie persists, that's unusual — systemd reaps aggressively. Possibilities:

• •You're in a container where PID 1 is your application (e.g., a Node or Python process) rather than a real init. This is the most common cause. Fix it by running your container with --init (Docker), or use tini/dumb-init as the entrypoint.
• •PID 1 is wedged, in which case you're looking at a reboot.

Root cause, for developers

If this is your own code, the parent needs to reap. Either loop explicitly:

while (waitpid(-1, NULL, WNOHANG) > 0);

...called from a SIGCHLD handler, or just tell the kernel you don't care about exit statuses:

signal(SIGCHLD, SIG_IGN);

That last one makes the kernel auto-reap, and is the simplest fix if you never need child exit codes.

In Python, subprocess.Popen objects leak zombies until you call .wait(), .poll(), or .communicate(). In shell scripts, background jobs started with & need a wait.