python进程不能直接当容器pid 1，因其默认不处理sigchld导致僵尸进程堆积，且无法可靠转发信号；推荐用tini等init进程代理pid 1职责。
为什么 Python 进程在容器里不能直接当 PID 1
因为 Linux 内核对 PID 1 有特殊要求：它必须能响应 SIGCHLD 来回收僵尸进程，还要能处理 SIGHUP、SIGTERM 等信号。而 Python 默认解释器**不处理 SIGCHLD**，也不转发信号给子进程——容器一启动多个子进程（比如 subprocess.Popen 调用的命令），很快就会堆满僵尸进程。
用 os.setsid() 和 signal.signal() 不够用
有人试过在 Python 脚本开头加 os.setsid() 或手动注册 SIGCHLD 处理器，但问题没解决：Python 的 signal 模块无法可靠捕获 SIGCHLD 并调用 os.waitpid(-1, os.WNOHANG) 清理所有子进程；而且容器终止时发的 SIGTERM 会被 Python 忽略或无法透传给子进程。
-
signal.signal(signal.SIGCHLD, handler)只能捕获一次，漏收很常见 - 子进程若自己 fork 出孙子进程，Python 更难追踪和回收
- Docker 默认用
--init启动容器时，其实就是在 PID 1 插了个轻量 init（如tini），不是靠 Python 自己扛
推荐方案：用 tini 作为容器 PID 1，Python 降级为普通进程
这是最稳妥、被 Kubernetes 和主流镜像广泛采用的做法。不用改 Python 逻辑，只改容器启动方式。
- 基础镜像选带
tini的（如python:3.11-slim已内置）或手动安装：apt-get install -y tini - Dockerfile 中写：
ENTRYPOINT ["/sbin/tini", "--"]，再接你的 CMD - 或者运行时加参数：
docker run --init your-image（Docker 1.13+ 原生支持） - 验证是否生效：进容器执行
ps -o pid,ppid,comm，看到tini是 PID 1、Python 是它的子进程，就对了
如果非要用 Python 当 PID 1，至少得做三件事
仅限调试或极简场景，生产环境不建议。核心是补全内核对 PID 1 的基本契约。
立即学习“Python免费学习笔记（深入）”；
- 用
signal.signal(signal.SIGCHLD, lambda s, f: os.waitpid(-1, os.WNOHANG))——但要循环调用，不能只注册一次 - 用
signal.signal(signal.SIGTERM, lambda s, f: sys.exit(0))显式退出，否则 Python 默认忽略 - 子进程必须用
start_new_session=True启动（避免共享会话），且禁用shell=True防止中间 shell 拦截信号 - 仍需轮询
os.waitpid()，因为SIGCHLD不保证每个子进程都触发一次信号
真正麻烦的是：一旦子进程又 fork 出新进程（比如调用 bash -c "sleep 10 &"），Python 就彻底失去控制权。这种链式派生在真实服务中太常见了。
