DEV Community

Cover image for The Linux process that even SIGKILL can't kill
Aditya Raj
Aditya Raj

Posted on

The Linux process that even SIGKILL can't kill

URL: https://www.youtube.com/watch?v=TLaLW84egMk

The short version, for anyone who'd rather read it:

When a process exits, the kernel frees basically everything: address space, file descriptors, and it never schedules the task again. What stays is a small record — the PID, the exit status, and some CPU accounting — because the parent may still want to read it. That record is the zombie. SIGKILL does nothing to it because there's nothing left to kill; the kill(2) call even returns success.

It's removed when the parent calls wait(). If the parent dies first, the children are reparented to the nearest ancestor marked as a subreaper (PR_SET_CHILD_SUBREAPER), and failing that to PID 1 of that PID namespace. The walk stops at the namespace boundary, so a process in a container is never adopted by anything on the host.

The part that bites in production: in a container your application is PID 1, which makes it the reaper for everything inside. Plenty of apps never call wait() on processes they didn't spawn directly, so orphans accumulate as zombies until the pids cgroup limit is hit and nothing can fork. Fixes are tini / docker run --init, initProcessEnabled on ECS, or shareProcessNamespace on k8s so the pause container does the reaping.

Top comments (1)

Collapse
 
aytidadev profile image
Aditya Raj

Any feedback would be really appreciated