解除启动限流
当服务在很短时间内反复失败，systemd 会按 StartLimitIntervalSec 与 StartLimitBurst 判定它进入了崩溃循环，于是停止继续拉起，单元停留在 failed 状态。此时即使修好了原因，直接 start 也可能被限流挡住。systemctl reset-failed 的作用就是清掉 failed 状态与重启计数，让它重新具备启动条件。
基本信息
| 适用平台 | Linux（systemd） |
|---|---|
| 命令语法 | systemctl reset-failed [单元...]（不带单元时清除全部失败状态） |
| 相关参数 | StartLimitIntervalSec 统计窗口、StartLimitBurst 窗口内允许的启动次数、Restart 重启策略、RestartSec 重启间隔 |
| 默认取值 | 较新 systemd 的默认窗口为 10 秒、次数上限为 5（以本机 systemctl --version 为准） |
| 观察入口 | systemctl status 与 journalctl 里的 start-limit-hit 提示 |
典型使用场景
- 修复配置后恢复服务：清计数再启动，避免被限流挡住
- 排障期间反复试错：每次改动前先清一次失败状态
- 崩溃循环取证：确认触发限流的是哪一条错误
- 变更后核对：确认服务能稳定启动并保持运行
- 批量处理：清掉多个残留的 failed 单元状态
常用示例
常用示例
systemctl status myapp --no-pager | head -n 15 # 看失败原因
journalctl -u myapp -n 30 --no-pager | grep -i 'start-limit' # 确认是否被限流
systemctl reset-failed myapp # 清计数
systemctl start myapp && systemctl is-active myapp # 重新启动并确认状态
systemctl --failed # 确认还有哪些失败单元调整限流参数（确有必要时）
调整限流参数（确有必要时）
# /etc/systemd/system/myapp.service
[Unit]
StartLimitIntervalSec=60 # 统计窗口 60 秒
StartLimitBurst=5 # 窗口内允许 5 次启动
[Service]
Restart=on-failure
RestartSec=5 # 启动失败后等 5 秒再重试观察与判断
| 命令或参数 | 作用 | 怎么看 |
|---|---|---|
| systemctl status | 运行状态与最近日志 | failed 会给出退出码与简要原因 |
| journalctl 里的 start-limit-hit | 明示触发了启动限流 | 看到它就说明是被限流而非配置错误 |
| StartLimitIntervalSec | 统计窗口长度 | 窗口太短会让正常重启也被判为循环 |
| StartLimitBurst | 窗口内允许的启动次数 | 调大只是拖延，不解决根因 |
| Restart 与 RestartSec | 重启策略与间隔 | Restart=no 时不会触发限流 |
先问「为什么失败」而不是急着调大 StartLimitBurst：触发限流说明服务在崩溃循环，放开限制只会让它更频繁地失败、日志更吵，根因仍然存在。reset-failed 是修复后的收尾动作，不是修复手段。
建议的排查顺序是：先 systemctl status 看退出码与简要原因，再 journalctl -u 看详细报错与是否出现 start-limit-hit，改完配置后执行 reset-failed，最后 start 并用 is-active 与 status 双重确认确实稳定运行，而不是只看 start 没有报错。
StartLimitIntervalSec 与 StartLimitBurst 在新版 systemd 里属于 [Unit] 段，早期版本曾放在 [Service] 段。写错段落不会报错但也不会生效，改完用 systemctl show 服务名 -p StartLimitBurst 核对实际取值。