ContainerRuntime资源清理机制与僵尸进程处理-Docker-PHP中文网

容器内僵尸进程不影响宿主机是因为PID namespace隔离，但容器PID 1不回收会导致pid_max耗尽而卡死；必须用tini等init或手动wait4轮询处理僵尸。

containerruntime资源清理机制与僵尸进程处理

为什么容器里 `ps aux | grep Z` 一堆僵尸，但宿主机完全没影响？

因为容器 PID namespace 隔离了进程视图——僵尸进程只存在于容器自己的进程表中，宿主机的 /proc 看不到它们，也不会耗尽宿主机的 PID 资源。真正危险的是：容器内 PID 1 进程不回收，pid_max（默认 32768）很快被占满，新 fork() 失败，应用直接卡死。

容器内 PID 1 必须主动调用 wait4() 或等价系统调用，内核不会代劳；普通进程退出时发 SIGCHLD，但没人处理就一直卡在 Z 状态
Go、Python、Node.js 等 runtime 默认不实现 init 行为，若直接作为 PID 1 启动（如 CMD ["./app"]），子进程退出后必留僵尸
docker run --init 是最轻量解法：它自动注入 tini（一个约 100KB 的 init 可执行文件），接管 PID 1 职责，无需改代码

Go 程序当 PID 1 时，不加 `wait4` 循环就是埋雷

Go runtime 不注册 SIGCHLD 处理器，也不后台轮询 wait4，哪怕你用 cmd.Process.Signal(syscall.SIGTERM) 终止子进程，漏掉 cmd.Wait() 就立刻变僵尸。

正确做法是：在主 goroutine 中启动非阻塞轮询，例如 for { _, err := syscall.Wait4(-1, nil, syscall.WNOHANG, nil); if err != nil && err != syscall.ECHILD { break } }
别用 signal.Notify 捕获 SIGCHLD 后再 wait——信号可能丢失，且 Go 的 signal 包不保证原子性
如果程序必须自己当 PID 1，记得忽略 SIGCHLD：signal.Ignore(syscall.SIGCHLD)，否则可能被反复中断轮询逻辑

`tini` 和 `dumb-init` 怎么选？别被名字骗了

两者都解决同一问题，但行为细节不同：tini 默认转发所有信号给子进程，dumb-init 默认只转发 SIGTERM 和 SIGINT，其余丢弃。这意味着如果你的应用依赖 SIGHUP 重载配置，用 dumb-init 就收不到。

推荐优先用 tini：Docker 官方 --init 默认就是它，Alpine 镜像里 apk add tini 即可，ENTRYPOINT ["/sbin/tini", "--"] 一行搞定
避免手写 ENTRYPOINT ["tini", "--", "./app"] 却忘了加 -- 分隔符，否则 tini 会把 ./app 当作自己的参数解析失败
不用 docker-init：它是 Docker Desktop 旧版绑定的二进制，已停止维护，且和 containerd 兼容性差

Kubernetes 里光靠 `pod.spec.restartPolicy` 压根不管僵尸

Pod 重启策略只管容器退出码，对容器内僵尸进程完全无感。即使你设了 Always，只要容器没退出，僵尸就能一直堆到 pid_max 溢出。

必须在 pod.spec.containers[].securityContext 中显式启用 init：runAsUser: 0 + privileged: false（确保能挂载 /dev/init），再配合镜像内预装 tini
别信 “K8s 会自动清理” —— 它只负责拉起/销毁整个容器，不介入容器内部的进程树管理
监控要落到容器内：通过 exec 进容器跑 ps -eo stat= | grep -c Z，而不是查宿主机的 /proc/[pid]/status