Docker报错dial unix /var/run/docker/containerd.sock连接拒绝的成因咨询

我之前帮不少团队排查过这类运行多日后突发的Docker连接问题，结合实际生产场景，主要成因大概有这几类，你可以对照自己的环境逐一排查：

• containerd进程异常退出或崩溃
  Docker底层核心依赖containerd管理容器的生命周期，如果containerd因为内存溢出、宿主机资源被其他进程耗尽（比如OOM Killer直接杀掉了containerd进程）、或者自身存在的bug触发崩溃，对应的sock文件就会失去进程监听，自然会出现连接拒绝的错误。你可以通过以下命令快速排查：

  • 查看containerd的系统日志：journalctl -u containerd
  • 检查宿主机的OOM记录：dmesg | grep -i oom

• /var/run目录的权限或存储异常
  你提到的/var/run是基于内存的临时文件系统（tmpfs），如果这个目录的权限被意外修改（比如某个操作把所有者改成了非root用户），Docker/containerd进程就无法读写sock文件；另外，如果tmpfs的空间被大量临时文件占满，也会导致无法创建或维护sock连接。可以用这些命令确认：

  • 查看sock文件的权限：ls -l /var/run/docker/containerd/
  • 检查tmpfs的空间使用：df -h /var/run

• Docker与containerd版本不兼容
  虽然一开始系统运行稳定，但如果后续有过组件的部分更新（比如只升级了Docker但没同步升级containerd，反过来也一样），长期运行后可能触发兼容性bug，导致进程间通信异常。可以用以下命令核对版本：

  • 查看Docker版本：docker version
  • 查看containerd版本：containerd --version
    官方文档里有明确的版本兼容矩阵，确保两者版本匹配是长期稳定运行的基础。

• 宿主机安全模块或网络规则干扰
  有些时候宿主机的SELinux、AppArmor等安全模块规则被更新，或者iptables/防火墙规则被误修改，会间接阻断Docker和containerd之间的sock通信；另外，宿主机的cgroup、namespace出现异常也可能影响进程间的正常交互。可以检查dmesg日志里是否有相关的权限拒绝记录，或者查看安全模块的审计日志。

• 长时间运行引发的资源泄漏
  Docker和containerd长期运行后，如果存在内存泄漏、文件句柄泄漏的问题，会逐渐耗尽系统资源，最终导致进程无法正常响应。比如containerd进程打开的文件句柄数达到系统限制（ulimit -n），就会无法处理新的连接请求。可以用这些命令排查：

  • 查看containerd进程的文件句柄占用：lsof -p $(pidof containerd)
  • 查看containerd的内存占用：ps aux | grep containerd

找到根源后，你就可以针对性地做预防措施（比如设置进程自动重启监控、定期清理临时资源、确保组件版本同步更新），不用每次都麻烦运维啦。

内容的提问来源于stack exchange，提问作者user8339674