【送书运动三期】解决docker服务假死题目

发表于 2026-10-3 20:37:26

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要登录才可以下载或查看，没有账号？立即注册

×

一、现象：Docker 假死，所有命令都没反应

用 docker-compose 部署容器时，偶尔会遇到这种情况：用 docker-compose stop 或 docker-compose down 想停掉容器，却停不掉，或者一直卡在「停止中」。 非常让人头疼。

典型的假死表现长这样：

docker ps：显示容器状态正常（还是 Up），但对外服务已经不可访问；
docker stats：完全没有任何反应；
docker stop <CONTAINER_ID>：没有反应；
docker restart <CONTAINER_ID>：没有反应；
docker exec -it --user root <ID> /bin/bash：进不去，没反应；
docker logs <ID> --tail 100 -f：没输出；
docker-compose stop / down：命令超时、提示不可用。

「全部命令都没反应」这个特征本身就是最重要的线索：不是某个容器坏了，而是 Docker 守护进程层面已经不响应了。

二、排查思路：从容器往守护进程一层层往上查

遇到这种情况，先别急着重启机器，按下面四步来，大部分能当场定位。

1. 看容器内部日志

先看容器的 stdout / stderr 输出，拿容器内部问题的更多信息：

docker logs <CONTAINER_ID>

加 -f 可以实时跟踪：

docker logs -f <CONTAINER_ID>

如果这里日志也毫无输出，说明容器层已经不是问题所在，往下走。

2. 看宿主机资源

docker stats

确认宿主机的CPU、内存没有被耗尽——资源打满是「假死」最常见的真实原因之一，尤其是内存耗尽触发大量换页时，整个 daemon 都会变得极其迟缓，看起来就像卡死。顺手 top 看一眼负载。

3. 看 Docker 守护进程状态

sudo systemctl status docker

检查守护进程是否在跑、有没有报错。如果守护进程出现异常，可以尝试重启 Docker 服务：

sudo systemctl restart docker

这一步是多数场景的终点。

4. 手动停起容器（有时能有意外收获）

尝试手动停止并启动容器，看能否绕过问题。

三、为什么「重启 docker 服务」通常能救回来

要把这件事说清楚，得区分两层：

容器层（containerd-shim、runC、cgroup、网络命名空间）：这里容易出现真正的僵死，比如某个 shim 卡住，容器状态还是 Up，但内部进程已经不响应；
守护进程层（dockerd）：它是通过 RPC 和容器层通信的。当容器层僵死或系统资源被耗尽时，dockerd 的调用会一直挂住，表现为「任何 docker 命令都没反应」。

所以 systemctl restart docker 实际做的是：把 dockerd 连同底层的 containerd 一起重启，让僵住的运行时重新初始化。这也是为什么「全部命令都没反应」时，重启 docker 服务往往比重启整个机器快得多，也更安全。

四、别漏掉的三个根因

磁盘满了（高频）：用 df -h 看 /var 和 overlay2 目录。磁盘写满会让 daemon 在写日志、写层时卡死，清理 /var/lib/docker 里无用的构建缓存和悬空镜像后通常立刻恢复；
文件描述符或进程数耗尽：ulimit -n、fs.file-max 打满，daemon 新建连接失败并阻塞；
存储驱动卡在 I/O 错误：磁盘有坏块时读写层会长时间阻塞。这种情况重启 docker 治标，要查磁盘。

五、事后怎么防：三条实在建议

给 daemon 加监控：对 systemctl status docker 和 docker info 做定期探测，假死是「悄悄发生」的，没人盯就永远不知道；
清理策略常态化：定期 docker image prune / docker builder prune，别让 /var 被镜像和构建缓存吃满；
给容器设资源上限：docker-compose 里配好 mem_limit / cpus，单个应用把机器吃死导致全站假死，是最不划算的事故。

六、最小排障顺序

1. docker logs <ID>           # 容器层有没有输出
2. top / df -h                 # 资源与磁盘有没有被打满
3. sudo systemctl status docker
4. sudo systemctl restart docker     #  daemon 层，通常到这步就活了
5. docker ps / docker stats     # 复核

七、一句话结论

Docker 假死的判断标准是「是容器坏了还是 daemon 坏了」：容器层问题 docker logs 会有输出；一旦 stats/stop/exec 全部无响应，那就是资源耗尽或运行时僵死，直接 systemctl restart docker。

但别停在重启这一步——先 df -h 和 top 找出真正的根因（磁盘满、内存满、fd 耗尽），再给容器加上资源上限。不然它会再死一次。

（本文由 qidao123.com企服评测-应用市场编辑提示整理：内容围绕 Docker 守护进程假死的排查与恢复，适用于容器化服务的稳定性运维。重启 docker 服务会影响本机所有容器，请在维护窗口执行。）