容器内 PID 1 进程必须主动回收孤儿进程，因其被内核强制收养子进程且不自动 wait 会导致僵尸进程；Tini 是官方推荐的轻量 init 方案，可自动收养、wait 和信号转发。

容器内 PID 1 进程不是普通进程，它是整个容器进程树的“根”和“守门人”。它必须承担三项硬性职责：收养孤儿进程、响应 SIGTERM/SIGINT 实现优雅退出、主动 wait() 回收已终止子进程（防止僵尸）。缺一不可，否则容器会卡住、信号失效或资源泄漏。

为什么容器里的 PID 1 必须自己处理孤儿回收

Linux 内核强制规定：父进程退出后，其子进程自动被 re-parent 到当前命名空间中 PID 为 1 的进程。在容器里，这个 PID 1 就是你的 CMD 启动的那个进程（比如 python app.py 或 nginx），而不是宿主机的 systemd。如果它不调用 wait() 或 waitpid()，子进程退出后就会变成僵尸——只留一个进程控制块（PCB），持续占用 PID 和少量内核资源。

常见误区是以为“反正有 init”，但容器里没有传统 init；若你直接用 bash、sh 或未适配的应用当 PID 1，它们默认不处理 SIGCHLD，也不自动 wait，僵尸就会越积越多，最终可能耗尽 PID 数量上限（尤其是长期运行的批处理或微服务）。

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

典型 PID 1 进程的能力对比

不同启动方式对孤儿回收的支持差异很大：

• 直接运行应用（如 nginx、node server.js）：多数能正确处理 SIGTERM，但一般不回收子进程（除非内置了 wait 逻辑）；若应用 fork 出守护子进程又不 wait，就会遗留僵尸
• /bin/sh 或 /bin/bash 作为 PID 1：bash 本身支持 wait，但默认不自动监听 SIGCHLD；且不转发信号给子进程组，docker stop 会超时失败
• systemd 或 sysvinit 容器：功能完整，但体积大、启动慢，通常不适用于云原生场景
• Tini（dumb-init 的轻量替代）：专为容器设计，最小开销；自动收养 + 自动 wait + 信号转发；Docker 官方推荐方案

用 Tini 配置容器 init 进程

这是最简单、最通用的解法。Tini 作为 PID 1 启动，再由它拉起你的主应用，所有子进程都由 Tini 统一托管：

• 在 Dockerfile 中启用：ENTRYPOINT ["tini", "--"]，随后 CMD 保持不变（如 ["python", "app.py"]）
• 或直接打包进镜像：RUN apt-get update && apt-get install -y tini（Debian/Ubuntu）或 apk add --no-cache tini（Alpine）
• 验证是否生效：进入容器执行 ps -o pid,ppid,comm，确认主应用的 PPID 是 1，且 Tini 显示为 PID 1
• 额外加固：加 --wait-for-exit 参数可让 Tini 等待所有子进程退出后再结束，避免主进程提前退出导致容器立即终止

应用层自主处理（适合定制化强的场景）

如果你坚持不用外部 init，需在代码中显式接管 SIGCHLD 并调用 wait：

• Python 示例：注册 signal.signal(signal.SIGCHLD, lambda s, f: os.waitpid(-1, os.WNOHANG))，并在主循环中定期检查
• Go 示例：启动 goroutine 监听 syscall.Wait4(-1, &status, syscall.WNOHANG, nil)
• 注意：必须使用 WNOHANG 非阻塞模式，避免主线程挂起；多次调用直到返回 0（无更多子进程可回收）