Python无法可靠获取容器崩溃的退出信号，应通过外部监控（如docker events）报警，并用tini或os.execv确保信号传递，避免在容器内使用supervisor等进程管理器。
容器崩溃时Python怎么拿到确切的退出信号
Docker容器挂掉，本质是主进程（ENTRYPOINT 或 CMD 指定的进程）退出。Python脚本如果直接作为 PID 1 运行，它收不到 SIGTERM 以外的大多数信号（比如 SIGKILL），也**无法感知父进程（即容器 runtime）是否已销毁**——它只知道自己“被杀了”，但不知道为什么、谁杀的。
真正可靠的方式是让 Python 主动监听容器健康状态，而不是等“被通知”。常见做法是：
- 在容器内定期调用
docker inspect --format='{{.State.Status}}' $(hostname)（需挂载/var/run/docker.sock）； - 更轻量的是检查
/proc/1/cgroup内容是否还包含docker-或libpod-字样（容器运行时标识）； - 最稳妥的是 Python 主进程自己写一个心跳文件（如
/tmp/alive.timestamp），由外部监控脚本轮询该文件的 mtime 是否超时。
Python如何在容器里安全地拉起自身进程
直接用 os.system('python app.py &') 或 subprocess.Popen 启动子进程，在容器中极易失控：新进程不是 PID 1，容器停止时不会收到信号，可能残留僵尸进程，且日志无法透出到 docker logs。
正确做法是让 Python **不接管 PID 1，而是交由容器初始化进程管理**：
立即学习“Python免费学习笔记（深入）”；
- 改用
tini作为ENTRYPOINT（Docker 官方推荐）：ENTRYPOINT ["/sbin/tini", "--"]
然后CMD ["python", "app.py"]； - 若必须用 Python 自己做重启逻辑，至少要用
os.execv替换当前进程，而非 fork 新进程：os.execv(sys.executable, [sys.executable] + sys.argv)
； - 避免使用
shell=True，防止启动 shell 中间层导致信号传递断裂。
报警触发点应该放在容器外还是容器内
容器内报警不可靠——容器一挂，里面所有进程全灭，报警代码根本没机会执行。所以报警必须由宿主机或编排系统触发。
推荐两种落地方式：
-
用
docker events监听容器状态变更：在宿主机跑一个 Python 脚本，持续读取docker events --filter 'event=die' --filter 'container=your-app'，匹配到后立即发钉钉/企业微信/Webhook； -
用
docker-compose up -d --no-deps --force-recreate配合健康检查：在docker-compose.yml中设置restart: on-failure+healthcheck，再用外部脚本轮询docker-compose ps --services --filter status=unhealthy； - 注意：不要依赖
docker logs实时抓异常字符串来报警——日志可能缓冲未刷盘，或容器已退出导致logs返回空。
为什么用 supervisor 或 systemd 在容器里管 Python 是错的
容器不是虚拟机，它的设计哲学是“一个容器一个关注点”。在容器内再起一套进程管理器（如 supervisord），会带来三个硬伤：
- PID 1 被 supervisor 占用，而它默认不转发信号给子进程，导致
docker stop超时后发SIGKILL，Python 来不及做清理； - supervisor 的日志输出不走 stdout/stderr，
docker logs看不到，排查时要进容器翻文件； - 它和 Docker 的 restart 策略（
on-failure,unless-stopped）功能重叠，反而增加故障面——比如 supervisor 认为进程活着，但 Docker 认为 healthcheck 失败，两者状态撕裂。
真正需要“自动拉起+报警”的场景，核心不在容器内部怎么做，而在厘清责任边界：容器 runtime 负责保活，外部监控系统负责感知与告警。Python 只需专注业务逻辑，保持可被信号中断、支持优雅退出即可。
