如何修复Docker镜像中进程无法接收宿主机停止信号的问题？

本文共计709个文字，预计阅读时间需要3分钟。

基本原因在于容器中+PID+1+进程不具备处理信号与子进程回收的能力。Linux内核对+PID+1+有特殊要求：

用 tini 替代默认 init 进程

tini 是 Docker 官方推荐的轻量 init 实现，仅约 100KB，无依赖，自动完成两件事：

• 将收到的 SIGTERM、SIGINT 等信号原样转发给它的唯一子进程（即你的应用）
• 持续调用 waitpid(-1, ...) 回收所有已退出的子进程，杜绝僵尸累积
• 当子进程退出时，tini 自动退出，容器随之终止

在 Dockerfile 中启用方式如下：

Debian/Ubuntu 基础镜像：

RUN apt-get update && apt-get install -y --no-install-recommends tini && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["python", "app.py"]

Alpine 镜像更简洁：

RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["./server"]

确保应用自身成为 PID 1 并支持信号

适用于单进程、无子进程、且代码层已实现信号监听的场景（如 Go/Node.js/Python 应用）。关键是要避免 shell 层中转——因为 shell 不会自动转发信号。

• 错误写法（sh 占据 PID 1，不转发）：CMD ["sh", "-c", "python app.py"]
• 正确写法（exec 替换 shell，python 直接成为 PID 1）：CMD ["sh", "-c", "exec python app.py"]
• Go 示例中需显式注册：signal.Notify(sigChan, syscall.SIGTERM, syscall.SIGINT)
• Node.js 示例中需监听：process.on('SIGTERM', () => { server.close(...); })

利用 Docker 内置 --init 选项（运行时补救）

无需修改镜像，适合测试或临时修复。Docker 1.13+ 自带轻量 init，功能等效于 tini：

docker run --init -d my-app:latest

该参数会在容器启动时自动注入一个 init 进程作为 PID 1，后续你的 CMD 命令变为其子进程。效果与在 Dockerfile 中配置 tini 一致，但优先级低于镜像内声明的 ENTRYPOINT。

验证是否生效的实操方法

不要只看容器是否退出，要确认信号真正抵达应用：

• 启动容器后，进入容器：docker exec -it <id> sh
• 执行：kill -TERM 1（向 PID 1 发 SIGTERM）
• 观察应用日志是否输出“收到 SIGTERM”“开始关闭”等清理信息
• 再检查：ps aux 确认无 Z（zombie）状态进程
• 最后执行：docker stop <id>，观察是否在 10 秒内干净退出