每个人都可以，
拥有SSL证书

在执行 systemctl start docker 的时候，直接扔回来一段报错：Job for docker.service failed because the control process exited with error code. 再跑 systemctl status docker.service，就能看到那句经典的 Start request repeated too quickly，最后标记为 Failed with result ‘exit-code’。这其实是 systemd 的自我保护机制在工作——服务在短时间内反复重启，被直接掐掉了。

遇到这种问题别急着重装，先看它到底在抱怨什么。journalctl -xeu docker.service 打出来的日志是最实在的线索。我习惯重点翻几种情况：daemon.json 里 JSON 写崩了、containerd 没正常跑、端口被占了，或者 SELinux 出来拦路。

有一次我碰到一条很具体的报错：Error initializing network controller: error creating default “bridge” network: ZONE_CONFLICT: ‘docker0’ already bound to ‘trusted’。这就是 SELinux 的安全区域跟 Docker 要创建的 docker0 网桥冲突了，服务刚起来就被拍死，反复几次后 systemd 直接不玩了。

如果你也在 /etc/docker/daemon.json 里配过镜像加速或者存储驱动，可以用 jq 快速检查一下格式： cat /etc/docker/daemon.json | jq . 能直接告诉你哪里有语法毛病。常见的问题包括末尾多了个逗号，像 “registry-mirrors”: [“https://mirror.example.com”,] 这种；还有 storage-driver 写了个系统不支持的值，或者镜像加速的地址没加 https://。

这几个地方配置文件一歪，docker 启动的时候就直接退出了。

除了配置，依赖的 containerd 也得确认一下。systemctl status containerd 看看跑没跑，如果没起来，启动它并 enable 一下，不然 Docker 肯定起不来。

再往下就是资源冲突。2375 端口被占的情况也不少，lsof -i :2375 看一下是谁在用，如果不是自己要的，kill 掉就行。但更隐蔽的是 SELinux 的问题。临时测试的时候，可以 setenforce 0 关掉 SELinux，如果这时候 Docker 能起来，基本就可以确定是策略在挡路。不过直接关 SELinux 不是最好的方案，更合理的是把它调到 permissive 模式或者加一条精确的策略，比如 semanage port -a -t docker_port_t -p tcp 2375。注意这条命令需要 policycoreutils-python 包，机器上没装的话得先装一下。

关于前面那个 ZONE_CONFLICT 的错误，有时候还需要手动把已经存在但状态不对的 docker0 删掉：ip link delete docker0，然后再重启 docker。

这步做完，配合 SEManage 对端口的处理，基本能解决这种由 SELinux 区域绑定引起的问题。

如果本身 daemon.json 没问题，依赖也在跑，端口没冲突，SELinux 也放行了，但服务还是反复起不来，还有一种可能是 systemd 的默认重启限制阈值太低。

可以给 docker.service 加一个 override 配置来调宽限制。做法是：

$ sudo mkdir -p /etc/systemd/system/docker.service.d $ sudo tee /etc/systemd/system/docker.service.d/override.conf <<EOF [Service] Restart=on-failure RestartSec=5s StartLimitIntervalSec=60s StartLimitBurst=3 EOF

然后 systemctl daemon-reload && systemctl restart docker。

这样把统计间隔拉到 60 秒，最多允许连续启动失败 3 次，每次重试间隔 5 秒，不再那么容易被触发保护。

配置文件如果是源头，我的处理方式是先把旧配置移走备份一下：

$ sudo mv /etc/docker/daemon.json /etc/docker/daemon.json.bak

再重新生成一个最小可用的配置，比如这样：

$ sudo tee /etc/docker/daemon.json <<EOF { “registry-mirrors”: [“https://registry.docker-cn.com”], “storage-driver”: “overlay2” } EOF

然后 reload 和重启服务。

问题解决后，确认一下服务状态、网络的 bridge 是否正常，用 docker network inspect bridge 看一眼，再 tail 一下 journalctl -fu docker.service 的日志，心里就有底了。下次再遇到这个报错，其实不用从头慌，按日志→配置→依赖→资源→systemd 限制这个顺序往下捋，大部分情况都能很快定位。