本质是容器pid 1未响应sigterm或子进程未回收，需分层排查：先确认状态与进程树，再调超时、验信号、清僵尸，最后才强制kill或清理元数据。
当 docker 容器在执行 docker stop 后长时间卡住、无响应，或报错 cannot stop container: tried to kill container, but did not receive an exit event，本质是容器主进程（pid 1）未响应 sigterm 信号，或存在子进程未被正确回收，导致容器无法完成优雅退出。这类“拒绝退出”故障需分层排查和处理，而非直接暴力清理。
确认容器当前状态与退出阻塞点
先明确问题性质，避免误操作：
- 运行
docker ps -a | grep <container_id></container_id>，确认状态是否为Up (healthy)或异常的Up (unhealthy)；若显示Up但docker stop卡住，说明进程仍在运行且未响应终止信号 - 执行
docker inspect <container_id> | jq '.State'</container_id>（或用grep -A 10 "State"），重点查看：
•"Status": "running"（确认未假死）
•"Pid"是否为非零值（为 0 表示已僵死，属另一类残留问题）
•"Running"和"FinishedAt"字段是否为空或异常 - 用
docker top <container_id></container_id>查看容器内实际运行的进程树，确认是否有长期驻留的后台进程（如未加-d的守护进程、nohup 进程、子 shell 等）未随主进程退出
向主进程发送 SIGTERM 并等待合理超时
Docker 默认发送 SIGTERM 后等待 10 秒，再发 SIGKILL。若应用本身支持优雅关闭，应确保它能在此窗口内完成清理：
- 手动触发一次标准停止并指定更长超时：
docker stop --time=30 <container_id></container_id>（例如给数据库或 Java 应用预留足够关闭时间） - 若仍失败，检查容器内主进程是否屏蔽/忽略 SIGTERM（常见于某些 C 程序未注册信号处理器，或 Java 应用未配置 shutdown hook）
- 进入容器验证信号接收能力：
docker exec -it <container_id> sh -c 'kill -0 1 && echo "PID 1 alive" || echo "PID 1 gone"'</container_id>
检查并清理僵持的子进程与僵尸进程
即使主进程退出，若其子进程未被 init（PID 1）正确回收，Docker 可能判定容器“未完全退出”：
- 在容器内执行
ps auxf，观察是否存在孤儿进程或状态为Z（zombie）的进程 - 若使用默认
sh或bash作为 PID 1，它不具备 init 功能，无法回收子进程 → 建议改用tini：在 Dockerfile 中添加ENTRYPOINT ["/sbin/tini", "--"] - 临时补救：进入容器后手动清理子进程链，例如
kill $(ps -eo pid= --ppid 1)（杀死所有直接子进程），再尝试exit让主进程自然结束
强制终止前的最后手段与安全清理
仅当确认无数据风险且上述方法均无效时，才升级操作：
- 先尝试
docker kill --signal=SIGQUIT <container_id></container_id>（部分应用对 SIGQUIT 更敏感，如 JVM 会输出线程 dump） - 再执行
docker kill --signal=SIGKILL <container_id></container_id>，跳过 SIGTERM 直接终结 - 若
docker kill也无响应（即 PID 1 已不可达但容器元数据卡住），说明已进入“半死”状态 → 按照 PID 为 0 的残留处理流程：停 docker 服务 → 清理/var/lib/docker/containers/<id>*</id>→ 清理local-kv.db→ 重启 dockerd
