PID 1 在容器中至关重要，因其需处理信号和回收僵尸进程；若应用直接作为 PID 1 且无信号处理能力，会导致 SIGTERM 无法传递、僵尸进程累积；推荐使用 tini 作为 init 进程转发信号并收尸，或确保单进程场景下应用直接运行于 PID 1 并支持信号处理。
在 Docker 容器中，进程信号（如 SIGTERM、SIGINT）无法正常传递给应用主进程，通常是因为容器启动时未正确处理 PID 1 的特殊性。Linux 内核对 PID 1 进程有特殊要求：它必须主动处理信号、回收僵尸子进程（wait for children），否则信号会被内核丢弃，子进程退出后变成僵尸，容器行为异常。
为什么 PID 1 在容器里这么关键
Docker 默认使用镜像中 ENTRYPOINT 或 CMD 指定的命令作为 PID 1 进程。如果该进程不是 init 系统（如 systemd、supervisord），也不具备信号转发和子进程收尸能力（比如直接运行 python app.py 或 node server.js），那么：
- SIGTERM 杀容器时，应用收不到终止信号，无法优雅关闭
- 子进程崩溃或退出后不被回收，持续累积为僵尸进程（
Z状态） -
docker stop超时后强制 kill -9，丢失数据或连接
推荐方案：用 tini 作为轻量级 init
tini 是 Docker 官方推荐的最小化 init 实现，专为容器设计，体积小（~100KB）、无依赖、自动转发信号、自动 reap 僵尸进程。
使用方式很简单，在 Dockerfile 中启用：
FROM python:3.11-slim # 安装 tini（Debian/Ubuntu） RUN apt-get update && apt-get install -y --no-install-recommends tini && rm -rf /var/lib/apt/lists/* <h1>或使用 Alpine（更小）</h1><h1>RUN apk add --no-cache tini</h1><h1>声明 tini 为入口点</h1><p>ENTRYPOINT ["/sbin/tini", "--"]</p><h1>后续 CMD 正常写你的应用</h1><p>CMD ["python", "app.py"]
这样容器真正 PID 1 是 tini，它会：
- 把收到的信号（如 SIGTERM）原样转发给子进程（即你的 Python 进程）
- 自动调用 waitpid() 回收所有已退出的子进程，避免僵尸
- 子进程退出后，tini 自身也退出，容器随之终止
替代方案：用 exec 启动（适用于单进程简单场景）
如果你确定容器只运行一个前台进程，且该进程本身能响应信号并无需 fork 子进程，可用 exec 替换 shell 进程，让应用直接成为 PID 1：
# 错误写法（shell 是 PID 1，不转发信号） CMD ["sh", "-c", "python app.py"] <h1>正确写法（exec 让 python 直接替换 shell）</h1><p>CMD ["sh", "-c", "exec python app.py"]
或者更简洁地：
CMD ["python", "app.py"] # 不经过 shell，直接执行，python 就是 PID 1
⚠️ 注意：只有当应用自身支持信号处理（如 Python 的 signal.signal()、Node.js 的 process.on('SIGTERM')）且不产生需管理的子进程时，才适合这种方式。
验证是否生效
运行容器后，进入检查进程树：
docker run -d --name test-app your-image docker exec test-app ps auxf
理想输出应类似：
PID USER TIME COMMAND
1 root 00:00:00 tini -- python app.py
12 root 00:00:00 python app.py
然后测试信号传递：
-
docker kill -s SIGTERM test-app→ 应用日志中看到 “received SIGTERM” 或正常关闭日志 - docker stop test-app → 在默认 10 秒内干净退出，无 Kill timeout 提示
