systemd 配置 Restart=always，仍因 Start request repeated too quickly 停止重试

服务配置了 Restart=always，启动失败几次后却停在 failed，日志出现 Start request repeated too quickly 或 start-limit-hit。重启策略仍受启动频率限制约束；触发限流后，systemd 不会仅仅因为等待窗口结束就自动补一次启动。

先查第一次启动为什么失败，修正后再清计数并启动。盲目关闭限流可能让错误进程不断消耗资源。以下配置语法适用于支持 StartLimitIntervalSec 的现代 systemd；旧发行版若报告未知指令，应按本机版本调整，不能忽略该警告。

最后一条限流信息前面，通常还有真正的失败原因

将 worker.service 替换为实际服务名，查看最近一次启动过程和生效参数：

sudo journalctl -u worker.service -b -n 200 --no-pager
systemctl cat worker.service
systemctl show worker.service -p Restart -p RestartUSec -p StartLimitIntervalUSec -p StartLimitBurst

从第一次退出开始读日志。如果出现配置错误、可执行文件不存在、权限拒绝或连接失败，先处理那一项。限流信息只解释为什么后来的启动请求被拒绝，不解释应用为什么第一次就退出。

查看实际属性也能避免把网上提到的默认“几次、几秒”当作本机固定值。发行版和管理员都可能调整默认值；手动启动与自动重启也都可能进入启动计数。

根因修正后，仅重置目标服务

在允许启动该服务、依赖已经准备好时，可执行：

sudo systemctl reset-failed worker.service
sudo systemctl start worker.service
systemctl status worker.service --no-pager

reset-failed 清除失败状态及计数，不修复应用、不自动启动服务。明确写服务名，避免同时抹掉其他故障单元的状态。启动命令可能触发应用初始化、任务消费或数据写入，先核对其重复执行是否安全。

若几次后又回到限流，返回前面的第一条失败日志。反复重置计数只会重复同一启动错误，还可能覆盖最有价值的现场信息。

临时失败需要等待时，给重试留间隔

确认服务设计允许自动重试，且会记录失败原因后，可以调整重启间隔。以下是一组示例覆盖设置，不是所有服务器都应使用的参数：

[Unit]
StartLimitIntervalSec=60s
StartLimitBurst=6

[Service]
Restart=on-failure
RestartSec=15s

限流参数属于 [Unit]，重启策略和间隔属于 [Service]。RestartSec 控制两次自动重启间的等待；启动计数还可能受到人工操作及其他激活来源影响，所以这组示例不能保证永远不触发限制。

Restart=on-failure 适用于异常退出才应重试的服务。若程序按设计正常退出后也必须再运行，原有 always 可能需要保留；不能为了参考配置而改掉业务语义。定时一次性任务也不应套成长驻服务不停重启。

修改前记录生效配置和原参数，通过目标服务的专用覆盖文件调整，在维护窗口应用：

sudo systemctl daemon-reload
sudo systemctl reset-failed worker.service
sudo systemctl restart worker.service

重启会停止现有进程；有正在处理的任务时按应用停机流程安排。撤回时恢复或移除本次添加的专用覆盖内容，保留其他覆盖文件，再重读并重启。

StartLimitIntervalSec=0 会关闭相应启动限流。只有已经评估持续失败的资源成本、重试副作用及监控告警时才考虑它；普通应用崩溃循环不宜先用这项设置掩盖。

成功不能只看一瞬间 active

至少覆盖原先容易触发故障的运行时段，检查日志是否仍不断出现相同异常、重启频率是否符合策略，以及服务的实际业务功能是否正常。服务成功启动后 PID 很快变化，通常仍需追查退出原因。

如果业务暂时无法恢复，可以停止目标服务避免继续重试，保留日志和失败证据；需要恢复时在根因处理后再按受控顺序启动。不要把清除了 failed 状态当作故障已经修好。