Docker 报错 Start request repeated too quickly 怎么解决？

这个报错到底在说什么

Docker 报错 Start request repeated too quickly 怎么解决？

先给结论：Start request repeated too quickly 不是病根，只是症状。

真正的原因是 Docker 服务（或容器）启动后几秒内就退出了，systemd 反复拉起，短时间内超过重启阈值，于是干脆罢工。

systemd 默认在 10 秒窗口内最多重启 5 次，超了就抛这个错并暂停重启。

所以排查的重点永远是一句话：它为什么一启动就退出？

报错的触发链路

整个过程其实挺机械的，拆开看就三步。

容器或服务启动后异常退出，退出码常见是 203、137 或其他非 0 值。

systemd 检测到退出，立刻按重启策略再拉一次。

短时间内拉起次数撞上阈值，报出 Start request repeated too quickly，进入冷却。

说白了，报错是"结果"，快速退出才是"原因"。盯着报错本身看半天是没用的。

第一步：先看日志找退出原因

退出前的日志是最值钱的线索，哪怕服务已经是 failed 状态也能翻出来。

直接重启往往只给一句没营养的提示：

[root@VM-20-17-opencloudos ~]# sudo systemctl restart docker
Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.

这时候接着看 journalctl -xe，真正的错误才会露出来：

[root@VM-20-17-opencloudos ~]# journalctl -xe
.....
docker.service: Start request repeated too quickly.
Main process exited, code=exited, status=203/EXEC
.....

这里的 status=203/EXEC 是个关键信号。

它表示 systemd 去执行启动命令时直接失败了，比如可执行文件路径不对、权限不够，或者配置把启动参数搞坏了。

不同根因对应的退出码不一样，所以日志里那行 status 一定要记下来再往下查。

第二步：按概率逐个排查

Docker 起不来，常见就那么几类问题，按出现频率从高到低过一遍。

配置文件写错了（最常见，八成是它）

/etc/docker/daemon.json 的格式或参数错误是头号嫌疑。

有个很典型的现象：安装时第一次启动是好的，后来改了配置再重启就挂了，这种情况九成出在这个文件上。

先把它清成一个最小可用配置，试试能不能起来：

{
  "registry-mirrors": [
  ]
}

然后执行：

sudo systemctl restart docker

如果空配置能正常启动，那就基本锁定是 daemon.json 的问题了。

接下来用笨办法定位：把可疑参数一行行删掉再重启，哪一行删了能起来，问题就在那行。

具体的坑通常是这两种：

• 不是合法 JSON，比如多了或少了逗号、括号没闭合
• 参数本身不被当前版本支持，Docker 不同版本的配置项是有差异的，老教程抄来的参数很可能已经废弃

Docker 主进程压根没起来

有时候是开机没有自启，重启服务器后服务就没拉起来。

补一下自启配置：

sudo systemctl daemon-reload
sudo systemctl enable docker

机器资源不够（CPU、内存）

内存被吃满时，进程刚拉起就被 OOM 干掉，退出码常见是 137。

先看一眼可用内存，重点关注 available 这一列：

free -h

如果 available 已经很紧张，那就不是 Docker 的锅，得先把内存腾出来。

常见问题

Q1. status=203/EXEC 具体是什么意思？

它表示 systemd 在执行 ExecStart 指定的命令时失败了。

常见原因是可执行文件路径错误、文件不存在或没有执行权限。

排查方向应该放在启动命令和文件本身，而不是容器内部逻辑。

Q2. 为什么安装时能启动，重启后就报这个错？

绝大多数是因为安装后改动过 /etc/docker/daemon.json。

首次启动用的是默认配置，没问题；后来加的参数或格式错误，要到下次重启才会暴露。

把配置清空验证一下就能确认。

Q3. daemon.json 怎么快速定位是哪一行写错了？

最直接的办法是先用最小配置确认服务能起来。

然后把原配置的参数一行行删掉、逐次重启，哪次删完能启动，问题就在刚删的那行。

虽然原始，但对付不熟悉的配置项很有效。

Q4. 退出码 137 和这个报错有关系吗？

137 通常意味着进程被 SIGKILL 杀掉，最常见的场景就是内存不足触发 OOM。

如果日志里看到 137，优先用 free -h 检查内存，而不是去翻配置文件。

写在最后

这个报错看着吓人，其实排查路径很固定：先看 journalctl 的 status，再按配置、自启、资源的顺序逐个排除。

需要提醒的是，daemon.json 的参数会随 Docker 版本变化，网上抄的配置不一定适用于你的版本，遇到不识别的参数别硬上。

以上排查思路基于常见的 systemd 管理场景，具体环境可能存在差异，实际操作时还是以你机器上的日志为准。

如果你也遇到过这个报错，或者卡在某个排查步骤上，欢迎在评论区聊聊你的情况～～～