容器无法正常停止的本质是sigterm未被响应或处理超时，最终触发不可控的sigkill强杀；docker先发可捕获的sigterm（默认等待10秒），超时后强制发送不可拦截的sigkill（退出码137），关键在于应用是否提前做好信号处理与优雅退出准备。
容器无法正常停止，本质是 SIGTERM 未被响应或处理超时，最终触发不可控的 SIGKILL 强杀。这不是“突然崩溃”，而是信号机制按规则执行的结果——关键在于你是否提前为这个流程做了准备。
理解 stop 的两阶段终止逻辑
Docker 执行 docker stop 时，不是直接杀死进程，而是分步推进：
- 先向容器内 PID 1 进程发送 SIGTERM（可捕获、可处理），默认等待 10 秒
- 若超时后进程仍在运行，再发 SIGKILL（编号 9，内核强制终止，无法拦截）
- 退出码为 137 是典型标志（128 + 9），说明最终被 SIGKILL 终止
为什么应用会忽略或卡住 SIGTERM
常见原因不是信号没送达，而是进程结构或代码没正确响应：
- PID 1 进程未正确转发信号（如用
sh -c "xxx"启动，shell 不转发 SIGTERM 给子进程） - 应用未注册信号处理器，或捕获后未做清理就阻塞/死循环
- 主进程是多线程程序，但只在主线程监听信号，子线程持有资源不释放
- 正在执行阻塞 I/O（如未设超时的数据库连接、文件写入、网络调用）导致无法及时退出
从代码和配置层面预防强杀
避免被 SIGKILL “背刺”，需在容器启动前和运行中双管齐下：
- 启动时加
--init参数（如docker run --init ...），用 tini 作为 PID 1，自动转发信号并回收僵尸进程 - 应用代码中显式监听
SIGTERM，并在 handler 中关闭监听端口、断开数据库、刷新缓冲区、等待活跃请求完成 - Docker 命令指定更合理的超时：
docker stop --time=30 my-app；Kubernetes 中设置terminationGracePeriodSeconds: 45 - 避免在容器中运行多个无管理的后台进程（如 & 启动的守护进程），它们可能脱离信号控制范围
强杀已发生时的应急与诊断
如果容器已经卡死或反复被 SIGKILL 终止，不要只依赖 docker kill 硬来，先定位根因：
- 查退出状态：
docker inspect my-container --format='{{.State.ExitCode}} {{.State.Status}} {{.State.Error}}'，确认是否为 137 及是否有错误描述 - 看日志线索：
docker logs --tail 100 --since "10m" my-container，重点找 SIGTERM 到达后的最后一行输出 - 进容器调试（若仍能 exec）：
docker exec -it my-container ps auxf，观察进程树和谁卡在 Running/Zombie 状态 - 强制清理仅作兜底：
docker rm -f my-container会跳过 stop 流程直接删，但可能遗留卷、网络或挂载点，后续需手动清理
