Docker Engine安装后服务崩溃本质是dockerd守护进程启动失败或运行中异常退出；需分层排查：先用systemctl status docker和ps aux | grep dockerd确认服务状态与进程存在性，再通过journalctl -u docker.service查原始日志定位ERROR/panic，接着验证overlay内核模块、存储驱动、内核版本及containerd/runc依赖是否就绪，最后用jq校验/etc/docker/daemon.json语法并检查bip等配置冲突。Docker Engine 安装后服务崩溃，本质是守护进程（dockerd）启动失败或运行中异常退出。这不是容器层面的问题，而是系统级服务稳定性问题。排查关键不在于重装，而在于分层定位：从系统依赖、服务状态、日志线索到配置冲突，逐层收紧范围。
看服务是否真在运行
先确认崩溃是“根本没起来”还是“起来又挂了”。执行：
- systemctl status docker —— 查看当前状态（active (running) / failed / activating / inactive）
- sudo systemctl is-active docker —— 只返回 active 或 inactive 或 failed，适合脚本判断
- ps aux | grep dockerd —— 直接查 dockerd 进程是否存在，避免 systemd 状态滞后误导
如果显示 failed，说明启动阶段就失败；如果显示 active 但很快变 inactive，说明运行中崩溃。
读守护进程原始日志
systemd 的 status 输出太简略，真正线索藏在 journal 日志里：
- sudo journalctl -u docker.service -n 100 -f —— 查最近 100 行并实时跟踪，重点找 ERROR、panic、failed to、cannot、permission denied
- sudo journalctl -u docker.service --since "2 hours ago" —— 回溯更早的启动尝试
- 若日志为空，说明 docker.service 没被 systemd 正确注册，需检查 /usr/lib/systemd/system/docker.service 是否存在且内容完整
查底层依赖是否就绪
Docker Engine 不是独立二进制，它强依赖内核模块、存储驱动和基础库：
- lsmod | grep overlay —— overlay2 驱动必须加载；未输出则运行 sudo modprobe overlay，并写入 /etc/modules-load.d/docker.conf 持久化
- docker info 2>/dev/null | grep "Storage Driver" —— 若命令报错或无输出，说明存储驱动初始化失败
- uname -r —— 内核低于 3.10（CentOS 7）或 4.15（Ubuntu 18.04）可能不兼容新版 Docker，需升级内核或降级 Docker
- containerd --version && runc --version —— 检查 containerd 和 runc 是否安装且版本匹配（Docker 24+ 要求 containerd.io ≥ 1.7.0）
验配置文件有没有硬伤
/etc/docker/daemon.json 是高频故障点，一个逗号错误就能让 dockerd 启动即退：
- sudo jq . /etc/docker/daemon.json —— 用 jq 校验 JSON 语法，报错即说明格式非法
- 常见错误：末尾多逗号、单引号代替双引号、中文标点、bip 地址网段与宿主机冲突（如设成 192.168.1.1/24，但宿主机 eth0 正用着 192.168.1.0/24）
- 临时绕过配置测试：sudo dockerd --debug --host unix:///var/run/docker.sock —— 手动前台启动，看是否立即报错，可快速区分是配置问题还是环境问题
