Stop getting burned by the way Kubernetes reaps your zombie processes

Technical Briefing | 11/10/2026

You spend all your time optimizing memory limits and CPU requests, but you eventually run into that one pod where the PID 1 is just a shell script or a poorly written app that doesn’t clean up after itself. When your entrypoint doesn’t properly wait for children, you end up with a process table full of zombies that hang around until the container dies. It’s a classic case of assuming the orchestrator handles process management, when in reality, it’s strictly a Linux kernel responsibility.

Why your PID 1 matters more than you think

In a standard Linux system, if a process dies, its parent adopts the zombie and cleans it up. In a container, if your entrypoint isn’t an init-aware process, it won’t reap the defunct entries created by spawned sub-processes. This bit me in prod during a migration where a legacy worker pod started leaking entries until the PID limit hit, effectively locking out new connections. Most people blame the app, but it’s really the lack of a proper signal propagation and reaping loop.

ps auxf | grep 'Z+    [defunct]'

• PID 1 must handle SIGCHLD to prevent zombies from lingering indefinitely
• Shell scripts used as entrypoints do not naturally reap child processes
• Using dumb-init or tini ensures your container survives the heavy lifting of process lifecycle

If you are already in a jam, check /proc/[pid]/status inside the container to see the NSpid fields. It’s a quick way to confirm if your process tree is behaving the way you expect. Next time you build a base image, skip the bare shell script entrypoint and use a lightweight init wrapper; it costs you almost zero overhead and saves you from the inevitable midnight restart of a hung container.