容器停止失败常因僵尸进程未被清理，DockerStop 不直接解决，需用tini等init替代PID 1的shell以回收僵尸进程，并避免应用产生不可控子进程。
容器停止失败常因僵尸进程未被正确清理，DockerStop 本身不直接解决该问题，但可通过合理配置和辅助手段规避。关键在于理解僵尸进程的成因及容器内 init 系统的作用。
为什么僵尸进程会让容器停不下来
Linux 中子进程退出后，若父进程未调用 wait() 获取其退出状态，该子进程会变成僵尸进程（Zombie），保留在进程表中。在容器中，若 PID 1 进程（如 sh、bash）不具备处理子进程退出信号的能力，就无法回收僵尸进程。而 Docker 在 stop 容器时会向 PID 1 发送 SIGTERM，并等待其退出；若 PID 1 因忙于其他任务或设计缺陷无法及时响应（例如被僵尸进程阻塞或未正确处理信号），stop 就会超时失败。
使用具备 init 功能的 PID 1 进程
替换默认 shell 为支持僵尸进程回收的 init 系统，是最直接有效的方案：
- tini：轻量级 init，官方推荐，Docker 内置支持（--init 参数）
- dumb-init：功能类似 tini，可作为 ENTRYPOINT 替代
- supervisord 或 s6-overlay：适合多进程复杂场景，自带子进程管理能力
示例：运行时启用 tini
docker run --init -it ubuntu:22.04
或在 Dockerfile 中指定：
ENTRYPOINT ["/sbin/tini", "--"]
避免在容器中产生不可控子进程
应用自身应尽量避免 fork 出长期运行又不被管理的子进程。常见风险点包括：
- Shell 脚本中后台命令未用 exec 替换当前进程（如
./server &应改为exec ./server） - Java 应用通过
Runtime.getRuntime().exec()启动子进程，但未定期调用waitFor()或destroy() - Node.js 使用
child_process.spawn()后未监听exit事件并做清理
stop 命令的合理使用与调试
Docker stop 默认有 10 秒超时，超时后发送 SIGKILL 强制终止。若频繁失败，可：
- 临时延长超时时间观察：
docker stop --time=30 <container> - 进入容器检查僵尸进程：
docker exec <container> ps aux | grep 'Z' - 确认 PID 1 行为：
docker exec <container> ps -p 1 -o comm=
若发现 PID 1 是 bash/sh 且存在大量 Z 状态进程，基本可判定为 init 缺失问题。
