docker守护进程启动失败应优先通过systemctl status docker和journalctl -u docker --no-pager -n 100定位原因，90%问题源于配置错误（如daemon.json语法或内核模块缺失）、依赖服务（如containerd）未运行或权限问题，重装是最后手段。
Docker守护进程无法启动，先别急着重装——90%的情况靠日志和状态检查就能定位，重装反而是最后一步。
查 systemctl 状态和启动失败原因
直接看服务是否卡在 failed 状态，以及具体哪一行报错：
- 运行
sudo systemctl status docker，重点看最后一段的Failed to start Docker Application Container Engine及其下方的journalctl -u docker --no-pager -n 50提示 - 常见错误如
failed to start daemon: error initializing graphdriver: overlay2: unknown option，说明/etc/docker/daemon.json里写了不支持的配置项 - 若显示
Unit docker.service entered failed state但无后续日志，大概率是依赖服务（如containerd）没起来，顺手跑一遍sudo systemctl status containerd
盯死 /var/log/docker.log 和 journalctl 输出
日志位置因发行版而异，journalctl 更可靠：
- Ubuntu/Debian 系统通常不写
/var/log/docker.log，优先用sudo journalctl -u docker --no-pager -n 100 - CentOS/RHEL 默认走 journald，但偶尔会 fallback 到
/var/lib/docker/daemon.log（需sudo权限读取） - 关键线索常藏在 “level=error” 行里，比如：
failed to mount overlay: invalid argument→ 内核不支持 overlay2；permission denied while trying to connect to the Docker daemon socket→ 不是 daemon 没启，而是 client 权限问题（别被误导）
验证底层依赖：containerd 和内核模块
Docker daemon 启动失败，经常不是它自己挂了，而是 containerd 崩了或内核缺东西：
- 手动启动
containerd：运行sudo systemctl start containerd，再查状态；失败则看journalctl -u containerd - overlay2 驱动需要内核支持：
zgrep CONFIG_OVERLAY_FS /proc/config.gz（若存在）或ls /lib/modules/$(uname -r)/kernel/fs/overlayfs/，空则说明内核没编译 overlay 模块 - cgroup v2 兼容性问题在 Ubuntu 22.04+ 很典型：若日志出现
cannot create cgroup directory，检查/proc/cgroups是否有name=systemd，再确认/etc/default/grub里没误加systemd.unified_cgroup_hierarchy=1
绕过 daemon.json 配置快速验证
很多启动失败是配置文件写错导致的，临时跳过它最能验明正身：
- 备份并清空
/etc/docker/daemon.json：sudo mv /etc/docker/daemon.json /etc/docker/daemon.json.bak - 执行
sudo systemctl daemon-reload && sudo systemctl restart docker - 如果这时能起来，说明原配置有问题；逐项恢复字段测试，特别注意拼写（如
"storage-driver"写成"sto rag e-driver"就直接拒启） - 常见坑：
"insecure-registries"里填了不可达地址、"bip"指定的 CIDR 和宿主机网段冲突、"data-root"路径权限不对或磁盘满
真正难搞的往往不是 daemon 启不动，而是它启了又秒退——这时候得盯着 journalctl -u docker -f 实时看，等它退出瞬间的日志，那行 error 才是命门。
