Claude on Question 13, Sep 25

How do I kill a zombie process in Linux that won't respond to SIGTERM?

The key thing to understand

You can't kill a zombie — it's already dead. A zombie (Z state, also shown as defunct) is a process that has exited but whose parent hasn't called wait()/waitpid() to collect its exit status. The kernel keeps a stub entry in the process table so the parent can retrieve that status.

Because there's no code executing, signals are meaningless. kill -9 <zombie_pid> will always appear to do nothing. The fix is to get the parent to reap it, or make the parent go away.

Step 1: Confirm and find the parent

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

Or with more context:

ps aux | grep -w 'Z\|defunct'

Note the PPID — that's your actual target.

Step 2: Nudge the parent

kill -CHLD <ppid>

A well-written parent that has a SIGCHLD handler but somehow missed the notification will reap the child. This works occasionally and is completely safe, so it's worth trying first.

Step 3: Kill the parent

If the parent is buggy or wedged (blocked in a syscall, stuck in a loop, never calls wait()), kill it:

kill <ppid>        # SIGTERM first
kill -9 <ppid>     # only if needed

When the parent dies, the zombie is re-parented to PID 1 (systemd or init), which reaps orphans immediately. The zombie disappears within a moment.

Check what the parent is before you do this. If it's sshd, a database, or an application server, killing it may be far more disruptive than the zombie. Zombies consume no memory or CPU — only a PID slot.

When you actually need to worry

Zombies are only a real problem if they accumulate and exhaust the PID space:

cat /proc/sys/kernel/pid_max     # usually 32768 or 4194304
ps -eo stat | grep -c '^Z'       # count zombies

A handful is cosmetic. Hundreds or thousands that keep growing means the parent has a genuine reaping bug — fix or restart the application rather than playing whack-a-mole.

If the parent is PID 1

This is common in containers. If your entrypoint is an application rather than a real init, it won't reap orphaned children and they pile up. Fixes:

docker run --init ...    # Docker injects tini as PID 1

Or bake tini / dumb-init into the image as the entrypoint. In Kubernetes, set shareProcessNamespace: true (the pause container reaps) or use a proper init in the image.

If PID 1 on a real host is leaking zombies, that's unusual — a reboot is the practical answer.

sha256 5e9190b2c939… · 33 tokens in · 1,624 out · 22.4 s · via Claude Platform on AWS · stopped on its own

Sep 25, the whole day Question 13, every day

Exact recordShowThe model id, the run, the verbatim text with line numbers and its full sha256

Model: anthropic/claude-opus-5
pinned anthropic/claude-opus-5-20260723; alias resolved to anthropic/claude-opus-5-20260723 at 2026-09-25 09:00:06 UTC (matches the pin)
Date: 2026-09-25 · run 20260925T090007Z-f08d1f · scorer v1
Scored: answered
sha256: 5e9190b2c9394900bee60370e81cc82b8ca58f8d48c9a8f5ec651337e4375c6c
Permalink: https://modeldrift.watch/r/2026-09-25/R1/anthropic/claude-opus-5/

Scored: answered
Received: 2026-09-25 09:05:39 UTC
Run: 20260925T090007Z-f08d1f
Served by: Claude Platform on AWS · HTTP 200 · finish stop
Size: 2,476 characters · 1,624 tokens out incl. hidden reasoning · 22.4 s

## The key thing to understand
You can't kill a zombie — it's already dead. A zombie (`Z` state, also shown as `defunct`) is a process that has exited but whose parent hasn't called `wait()`/`waitpid()` to collect its exit status. The kernel keeps a stub entry in the process table so the parent can retrieve that status.
Because there's no code executing, signals are meaningless. `kill -9 <zombie_pid>` will always appear to do nothing. The fix is to get the **parent** to reap it, or make the parent go away.
## Step 1: Confirm and find the parent
```bash
ps -eo pid,ppid,stat,comm | awk '$3 ~ /^Z/'
```
Or with more context:
```bash
ps aux | grep -w 'Z\|defunct'
```
Note the PPID — that's your actual target.
## Step 2: Nudge the parent
```bash
kill -CHLD <ppid>
```
A well-written parent that has a `SIGCHLD` handler but somehow missed the notification will reap the child. This works occasionally and is completely safe, so it's worth trying first.
## Step 3: Kill the parent
If the parent is buggy or wedged (blocked in a syscall, stuck in a loop, never calls `wait()`), kill it:
```bash
kill <ppid>        # SIGTERM first
kill -9 <ppid>     # only if needed
```
When the parent dies, the zombie is re-parented to PID 1 (`systemd` or `init`), which reaps orphans immediately. The zombie disappears within a moment.
**Check what the parent is before you do this.** If it's `sshd`, a database, or an application server, killing it may be far more disruptive than the zombie. Zombies consume no memory or CPU — only a PID slot.
## When you actually need to worry
Zombies are only a real problem if they accumulate and exhaust the PID space:
```bash
cat /proc/sys/kernel/pid_max     # usually 32768 or 4194304
ps -eo stat | grep -c '^Z'       # count zombies
```
A handful is cosmetic. Hundreds or thousands that keep growing means the parent has a genuine reaping bug — fix or restart the application rather than playing whack-a-mole.
## If the parent is PID 1
This is common in containers. If your entrypoint is an application rather than a real init, it won't reap orphaned children and they pile up. Fixes:
```bash
docker run --init ...    # Docker injects tini as PID 1
```
Or bake `tini` / `dumb-init` into the image as the entrypoint. In Kubernetes, set `shareProcessNamespace: true` (the pause container reaps) or use a proper init in the image.
If PID 1 on a real host is leaking zombies, that's unusual — a reboot is the practical answer.

End of response · 63 lines · 2,476 characters · sha256 5e9190b2c9394900bee60370e81cc82b8ca58f8d48c9a8f5ec651337e4375c6c