升级Docker后服务无法启动，核心是查看systemd服务日志（如journalctl -u docker.service）定位daemon初始化失败原因，而非容器日志；常见报错包括存储驱动不支持、containerd/runc版本不匹配、插件加载失败或权限问题，需同步检查daemon.json配置、内核模块及组件版本兼容性。
升级 Docker 后服务起不来，核心是查 守护进程（daemon）启动失败的日志，而不是容器日志。重点看 systemd 服务日志和 Docker 自身初始化过程的报错，而非 docker ps 或容器相关命令。
直接查看 Docker 服务启动日志
升级后服务无法启动，说明 daemon 没起来，此时 docker ps 会报 “Cannot connect to the Docker daemon”，这是结果，不是原因。真正线索在系统服务日志里：
- 运行
sudo journalctl -u docker.service -n 100 --no-pager，看最后 100 行启动过程中的错误 - 加
--since "1 hour ago"可聚焦升级后的时段：sudo journalctl -u docker.service --since "1 hour ago" - 若日志被轮转过，用
sudo journalctl -u docker.service -b查看当前 boot 的完整日志
重点关注几类典型报错
升级失败常触发底层兼容性或配置冲突，日志中高频出现的关键词可快速定位：
- “failed to start daemon” 或 “daemon failed to start”：说明进程启动阶段就中止，多因依赖缺失或内核模块不匹配
- “storage driver … not supported” 或 “failed to initialize graphdriver”：新版本 Docker 可能弃用旧存储驱动（如 aufs），而 /etc/docker/daemon.json 中仍强制指定
- “containerd: version mismatch” 或 “runc: invalid argument”：升级时 containerd、runc 等组件版本未同步，或残留旧二进制文件
- “failed to load plugin” 或 “plugin registration failed”：第三方插件（如 volume 插件、网络驱动）与新版不兼容
- “permission denied on /var/run/docker.sock” 或 “failed to create listener”：升级后用户组或 socket 权限重置，或 selinux/apparmor 规则拦截
配合检查关键配置与环境状态
光看日志不够，需同步验证几个升级后易出问题的环节：
- 检查 daemon.json 是否含已废弃参数：
sudo cat /etc/docker/daemon.json，特别留意storage-driver、graphdriver、exec-opts等字段是否仍沿用旧版写法 - 确认 containerd 和 runc 版本兼容：
containerd --version和runc --version，对照 Docker 官方文档的版本矩阵 - 验证 overlay2 内核支持：
lsmod | grep overlay，若无输出，需sudo modprobe overlay并加入/etc/modules-load.d/docker.conf - 检查 /var/lib/docker 目录权限：
ls -ld /var/lib/docker，应为drwx------ 1 root root；若属主异常，可能因升级脚本误改
临时回退与验证方式
若日志明确指向某组件不兼容，可快速验证是否为升级引入的问题：
- 停止服务：
sudo systemctl stop docker - 备份当前配置：
sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak - 清空或注释 daemon.json 中非必要配置，保留最小可用项（如仅留
{}） - 尝试启动：
sudo systemctl start docker，成功则逐步恢复配置项定位问题点 - 若仍失败，考虑降级：
sudo apt install docker-ce=（Debian/Ubuntu）或sudo yum downgrade docker-ce（RHEL/CentOS）
