Claude on Question 13, Sep 14

The key thing to understand

You can't kill a zombie — it's already dead. A zombie (state Z, sometimes shown as defunct) is just a leftover entry in the process table holding an exit status that the parent process never collected via wait(). There's no code running, no memory mapped, nothing to signal. SIGTERM, SIGKILL, whatever — signals are delivered to running processes, and a zombie isn't one.

So the fix is always to deal with the parent.

Find the zombies and their parents

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

Or for a quick count:

ps -eo stat | grep -c '^Z'

The second column is the PPID — that's your actual target.

Escalating fixes

1. Nudge the parent with SIGCHLD

kill -s SIGCHLD <ppid>

This tells the parent "hey, a child exited, go reap it." Works if the parent has a functioning SIGCHLD handler but somehow missed the notification. Often it won't help, because the usual cause is a parent that simply never calls wait() at all — a bug you can't signal your way out of.

2. Kill the parent

kill <ppid>        # try TERM first
kill -9 <ppid>     # if it's stuck

When the parent dies, orphaned zombies are re-parented to PID 1 (systemd/init), which reaps children automatically. They'll vanish within moments.

Obviously, check what the parent is before you do this — ps -p <ppid> -o comm,args. Killing the buggy app is fine; killing your database because it leaked a few zombies is less fine.

3. Restart the service properly

If the parent is a managed service, do it the clean way:

systemctl restart <service>

4. If the parent is PID 1

Zombies parented directly to PID 1 that aren't being reaped mean init itself is wedged or you're in a container with a non-reaping PID 1 (very common — a shell script or app running as PID 1 in Docker). For containers, restart the container and use --init or tini as PID 1 going forward. For a real host, this is a reboot.

Make sure they're actually zombies

This trips people up constantly. If ps shows state D (uninterruptible sleep), that's not a zombie — that's a live process blocked in a kernel syscall, usually waiting on I/O from a hung NFS mount, a failing disk, or a stuck device driver. Those genuinely ignore SIGKILL and there's no userspace fix; you need to clear the underlying I/O problem (e.g. umount -f, or fix the storage) or reboot.

ps -eo pid,stat,wchan:30,comm | grep ' D'

The wchan column shows which kernel function it's stuck in, which usually points straight at the culprit.

Do you even need to act?

A handful of zombies is harmless — each consumes one process table slot and a few hundred bytes. They're an annoyance, not an outage.

They matter when they accumulate, because they exhaust the PID space:

cat /proc/sys/kernel/pid_max    # usually 32768 or 4194304

Hit that ceiling and fork() starts failing system-wide — no new processes, possibly no new SSH sessions. If you see a steadily climbing zombie count, that's a leak in the parent application and worth filing a bug or patching, since restarting the parent is only ever a temporary workaround.