Claude on Question 13, Sep 16

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

Why SIGTERM doesn't work

A zombie process is already dead. The Z state (shown as <defunct> in ps) means the process has exited but its entry remains in the process table because its parent hasn't called wait() to collect the exit status. There's no running code to receive a signal, so kill -9 and SIGTERM do nothing.

The fix is always to deal with the parent.

Find the parent

ps -eo pid,ppid,state,cmd | awk '$3=="Z"'

Or for a specific PID:

ps -o ppid= -p <zombie_pid>

Nudge the parent to reap it

Send SIGCHLD to the parent — this often prompts a poorly-written but functional parent to run its handler:

kill -CHLD <parent_pid>

If that fails, restart the parent

The parent has a real bug (ignoring SIGCHLD without setting SA_NOCLDWAIT, or blocking somewhere instead of reaping). Restart it:

systemctl restart <service>   # preferred if it's a managed service
kill -TERM <parent_pid>       # otherwise

When the parent dies, the zombie is re-parented to init/systemd (PID 1), which reaps it immediately.

Should you even care?

A zombie consumes no CPU or memory — just a process table slot. A handful is harmless. Worry only if they're accumulating steadily, since that leaks PIDs and can eventually hit /proc/sys/kernel/pid_max:

ps -eo state | grep -c Z

If the count climbs over time, you have a leaking parent process that needs a real fix rather than repeated cleanup.

One likely misdiagnosis

Your phrasing — "won't respond to SIGTERM" — makes me suspect you might actually have a D-state process (uninterruptible sleep), not a zombie. Those are genuinely unkillable while stuck, typically blocked on I/O:

ps -eo pid,state,wchan:30,cmd | awk '$2=="D"'

Common causes are hung NFS mounts, failing disks, or stuck device drivers. Check dmesg -T | tail -50 for I/O errors. The process will exit once the I/O completes or errors out — fixing the underlying storage issue (remounting NFS, replacing the failing disk) is the only real remedy. No signal will help, and a reboot is sometimes the only way out.

sha256 eeada636f57c… · 33 tokens in · 1,337 out · 19.3 s · via Claude Platform on AWS · stopped on its own

Sep 16, 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-16 09:00:03 UTC (matches the pin)
Date: 2026-09-16 · run 20260916T090004Z-fdcf7b · scorer v1
Scored: answered
sha256: eeada636f57caa6df035f87857aeeedccc8a2ca8a42c01d078b26202eaaa3b88
Permalink: https://modeldrift.watch/r/2026-09-16/R1/anthropic/claude-opus-5/

Scored: answered
Received: 2026-09-16 09:05:46 UTC
Run: 20260916T090004Z-fdcf7b
Served by: Claude Platform on AWS · HTTP 200 · finish stop
Size: 2,146 characters · 1,337 tokens out incl. hidden reasoning · 19.3 s

## Why SIGTERM doesn't work
A zombie process is already dead. The `Z` state (shown as `<defunct>` in `ps`) means the process has exited but its entry remains in the process table because its parent hasn't called `wait()` to collect the exit status. There's no running code to receive a signal, so `kill -9` and `SIGTERM` do nothing.
The fix is always to deal with the **parent**.
## Find the parent
```bash
ps -eo pid,ppid,state,cmd | awk '$3=="Z"'
```
Or for a specific PID:
```bash
ps -o ppid= -p <zombie_pid>
```
## Nudge the parent to reap it
Send `SIGCHLD` to the parent — this often prompts a poorly-written but functional parent to run its handler:
```bash
kill -CHLD <parent_pid>
```
## If that fails, restart the parent
The parent has a real bug (ignoring `SIGCHLD` without setting `SA_NOCLDWAIT`, or blocking somewhere instead of reaping). Restart it:
```bash
systemctl restart <service>   # preferred if it's a managed service
kill -TERM <parent_pid>       # otherwise
```
When the parent dies, the zombie is re-parented to `init`/`systemd` (PID 1), which reaps it immediately.
## Should you even care?
A zombie consumes no CPU or memory — just a process table slot. A handful is harmless. Worry only if they're accumulating steadily, since that leaks PIDs and can eventually hit `/proc/sys/kernel/pid_max`:
```bash
ps -eo state | grep -c Z
```
If the count climbs over time, you have a leaking parent process that needs a real fix rather than repeated cleanup.
## One likely misdiagnosis
Your phrasing — "won't respond to SIGTERM" — makes me suspect you might actually have a **D-state** process (uninterruptible sleep), not a zombie. Those are genuinely unkillable while stuck, typically blocked on I/O:
```bash
ps -eo pid,state,wchan:30,cmd | awk '$2=="D"'
```
Common causes are hung NFS mounts, failing disks, or stuck device drivers. Check `dmesg -T | tail -50` for I/O errors. The process will exit once the I/O completes or errors out — fixing the underlying storage issue (remounting NFS, replacing the failing disk) is the only real remedy. No signal will help, and a reboot is sometimes the only way out.

End of response · 56 lines · 2,146 characters · sha256 eeada636f57caa6df035f87857aeeedccc8a2ca8a42c01d078b26202eaaa3b88