Docker 容器运行时故障排查：从现象到恢复的实战指南

场景

您的生产 Web 服务刚刚返回了 502。监控面板显示运行 API 的容器已经消失。您 SSH 到主机上，发现一个容器卡在重启循环中——或者更糟，已经退出并出现 OCI 运行时错误。这不是应用代码崩溃，而是容器运行时无法启动或维持执行。本文章将带您走过在 Linux 主机上排查 Docker 容器运行时问题的真实路径。

症状

常见迹象表明问题出在运行时而不是应用：

• 容器立即退出，退出码为 137（SIGKILL）或 139（SIGSEGV）。
• docker inspect 显示 State.Error 消息，如：OCI runtime exec failed: exec failed: unable to start container process: exec: '/bin/sh': stat /bin/sh: no such file or directory。
• 健康检查失败，容器进入重启退避循环。
• Docker 守护进程返回：Error response from daemon: containerd: container did not start before required deadline。
• 容器因 OOM 或达到 cgroup 限制而被杀死。

诊断

首先运行 docker ps -a 获取容器 ID 和退出状态。然后使用 docker inspect 查看重启次数、退出码和具体错误。在操作容器之前，务必收集日志。

常用命令：

docker ps -a --filter 'name=your-service'
docker inspect <container_id> --format '{{.State.ExitCode}} {{.State.Error}}'
docker logs <container_id> --tail 200 --timestamps
docker stats --no-stream

Docker 运行时依赖 containerd 和 runc。检查它们的健康状态：

systemctl status docker containerd
docker info | grep -i runtime
runc --version

如果错误发生在更底层，请检查内核消息：

dmesg | tail -50
journalctl -u containerd --since '10 minutes ago'

风险控制

• 在采取任何操作前，使用 docker inspect 和 docker logs 保存当前状态。
• 优先使用优雅停止：docker stop -t 30 <container_id> 而不是立即终止。
• 除非系统完全挂起，否则不要对生产容器运行 docker rm -f，并且必须先拉取日志并确认替换镜像可用。
• 启动新容器时，应设置内存和 CPU 限制，例如 --memory=512m --cpus=0.5，以避免耗尽主机资源。
• 如果使用自定义运行时（如 gVisor），请在重启前确认运行时已正确安装和配置。

回滚

如果故障发生在部署之后，请回滚到上一个镜像标签。例如：

docker pull your-app:stable
docker run -d --name your-app-rollback --env-file .env your-app:stable

将您的部署管理器（Kubernetes、Docker Swarm 或 systemd 单元）更新为使用旧标签。如果错误是由镜像中的二进制文件缺失或入口点配置错误引起的，那么回滚到先前可工作的镜像通常可以在几分钟内恢复服务。

验证

恢复后，验证容器是否稳定：

• docker ps 显示容器正在运行。
• docker logs --tail 20 显示正常的启动日志。
• 服务的健康端点返回 200 OK。
• 运行 docker inspect 确认没有重启策略峰值。

至少监控 10 分钟，以确保修复是持久的。

何时提交 OpsGlobal 工单

在以下情况下，请升级到 OpsGlobal：

• 回滚到已知良好镜像后，运行时错误仍然存在。
• 系统日志中出现类似 runc: symbol lookup error 或 overlayfs: mount error 的消息。
• 集群中的多个主机出现相同的故障模式。
• 您怀疑是内核或硬件层面的问题（缺页错误、I/O 错误、NUMA 问题）。

OpsGlobal 可以对 Docker 守护进程、containerd、runc 和内核参数进行深入诊断，然后应用热修复或长期稳定性配置。