Claude on Question 13, Oct 3

The short answer: you can't kill a zombie — it's already dead

A zombie (shown as Z or <defunct> in ps) is a process that has already terminated. All it is at this point is an entry in the kernel's process table holding its exit status, waiting for its parent to call wait()/waitpid() and collect it. There's no running code, no memory map, nothing to signal. That's why SIGTERM and even SIGKILL do nothing.

The real problem is the parent process that isn't reaping its children.

Find the zombies and their parents

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

Or:

ps aux | grep -w defunct

The PPID column is what you care about.

Step 1: Nudge the parent

Send SIGCHLD to the parent to prompt it to reap:

kill -s SIGCHLD <PPID>

A well-behaved parent with a proper handler will call wait() and the zombie disappears. If nothing happens, the parent has a bug (lost/ignored SIGCHLD, blocked in a loop, never calls wait() at all).

Step 2: Kill or restart the parent

When the parent dies, its zombie children are re-parented to PID 1 (init/systemd), which reaps orphans automatically.

# graceful first
kill <PPID>

# or if it's a service
systemctl restart <service>

Only use kill -9 on the parent if a normal TERM fails — it skips cleanup handlers and can leave behind sockets, lock files, or temp data.

Step 3: If the parent is PID 1

If zombies are parented to systemd and persisting, something is genuinely wrong — that's usually a kernel or container-runtime issue. In containers this is common when your entrypoint is a shell script or app that isn't a proper init: run with docker run --init, or use tini/dumb-init as PID 1.

Make sure it's actually a zombie

People often confuse zombies with processes stuck in D state (uninterruptible sleep). Those genuinely ignore SIGKILL and do hold resources:

ps -eo pid,stat,wchan:20,comm | awk '$2 ~ /^D/'

D state means the process is blocked in a kernel call — typically a hung NFS mount, a failing disk, or a stuck device driver. You can't kill it; you have to fix the underlying I/O (remount with umount -f -l, restore network to the NFS server, replace the dying disk). cat /proc/<pid>/stack and dmesg will usually point at the cause.

Do you even need to fix it?

A handful of zombies is harmless — each consumes one process-table slot and a few hundred bytes. It only matters if they accumulate toward kernel.pid_max (check with sysctl kernel.pid_max), which eventually prevents new process creation. A steadily growing zombie count is a strong signal of a bug in the parent application worth reporting or patching.

Rebooting works as a last resort, but it's treating the symptom — the parent will do it again.