Claude on Question 13, Sep 17

The key insight: you can't kill a zombie

A zombie (state Z, shown as <defunct>) is already dead. It's not a running process — it's just an entry in the process table holding an exit status, waiting for its parent to call wait()/waitpid() and collect it. Since there's no code executing, signals have nowhere to go. SIGTERM, SIGKILL, anything — all ignored.

The problem isn't the zombie. It's the parent process that isn't reaping its children.

Find the parent

ps -eo pid,ppid,stat,cmd | awk '$3 ~ /^Z/ { print }'

Or with ps aux, zombies show up with Z in the STAT column and <defunct> in the command.

Option 1: Nudge the parent

kill -s SIGCHLD <parent_pid>

This tells the parent "hey, a child died, go reap it." Works if the parent has a working SIGCHLD handler but somehow missed the notification. Often it doesn't help, because the reason you have zombies is that the parent has no handler or is stuck.

Option 2: Kill the parent

kill <parent_pid>          # try graceful first
kill -9 <parent_pid>       # if that fails

When the parent dies, the zombie is re-parented to init/systemd (PID 1), which reaps orphans automatically. The zombie disappears within moments.

Obvious caveat: make sure killing the parent is acceptable. If the parent is sshd, your web server, or a database supervisor, you're trading a harmless zombie for real downtime. Restarting the service properly (systemctl restart foo) accomplishes the same thing more safely.

Should you even care?

A handful of zombies consumes one PID slot each and essentially zero memory or CPU. It's cosmetically annoying, not harmful.

It matters when they accumulate — thousands of zombies can exhaust the PID space and you'll start seeing fork: Resource temporarily unavailable. Check your limit:

cat /proc/sys/kernel/pid_max
ps -eo stat | grep -c Z

Steady accumulation means a genuine bug in the parent: it's forking without ever calling wait(). The real fix is in that program — install a SIGCHLD handler, or set signal(SIGCHLD, SIG_IGN) so the kernel auto-reaps. In containers this is common with an application as PID 1 that doesn't reap; the fix is a proper init like tini or docker run --init.

One common mix-up

If signals genuinely aren't working and the state is D rather than Z, that's uninterruptible sleep, not a zombie. That process is alive but blocked in a kernel call — usually hung I/O, a dead NFS mount, or a failing disk. It also can't be killed, but for entirely different reasons, and the fix is addressing the underlying I/O problem (remount the NFS share, check dmesg for disk errors). Sometimes only a reboot clears it.