systemd 服务反复重启：从退出码到速率限制排查

systemd 服务反复重启时，真正要排查的不是一个“重启开关”，而是一条相互关联的故障链：服务进程先退出，Restart= 决定这次退出是否应该重启，RestartSec= 决定等待多久，启动速率限制再判断短时间内是否已经尝试过多，最后单元才可能进入 failed 状态。

因此，正确顺序是：先保存退出码、信号和日志证据，再核对生效的重启策略与速率参数；修复程序、权限、依赖或配置根因后，才执行 reset-failed 并重新启动。只把 StartLimitBurst 调大，通常只是让故障进程更频繁地消耗 CPU、日志和下游资源。

官方地址：https://systemd.io/

先保护可用性与故障证据

反复重启首先威胁三类资产：业务可用性、依赖系统的稳定性，以及能够解释根因的日志证据。服务每次启动都可能重新建连、抢锁、加载缓存或提交任务；高频失败会把局部问题放大为数据库连接风暴、消息重复消费、磁盘日志暴涨或告警洪水。

排查前不要立即循环执行 restart。先读取当前状态和最近一次主进程结果，并记录此刻的重启次数。下面这些字段比一句“服务失败了”更能区分故障发生在哪一层。

# 查看当前状态、最近日志摘要和主进程退出信息。
sudo systemctl status demo.service --no-pager -l

# 读取可用于判断的生效状态、退出结果、重启策略和速率参数。
sudo systemctl show demo.service \
  -p ActiveState -p SubState -p Result \
  -p ExecMainCode -p ExecMainStatus \
  -p Restart -p RestartUSec -p NRestarts \
  -p StartLimitIntervalUSec -p StartLimitBurst

ExecMainCode 表示主进程是正常退出、收到信号还是以其他方式结束，ExecMainStatus 保存对应的退出状态或信号值，Result 则概括单元最终结果。NRestarts 可以帮助判断这是一次偶发退出，还是已经进入持续重启。不同发行版和 systemd 版本可能带有不同默认值，所以应以 systemctl show 输出的生效值为准。

把反复重启拆成五个静态环节

第一环是进程为什么退出。非零退出码、未捕获信号、启动超时、看门狗超时和正常退出并不是同一种事件。程序配置错误、执行文件不可用、目录权限不正确、环境变量缺失、依赖端口未就绪，都可能让主进程很快退出。

第二环是Restart= 是否匹配这次退出。官方文档规定，Restart=on-failure 会在非零退出、未捕获的异常信号、超时或看门狗故障等情况下重启，适合大多数长期运行服务；Restart=always 连干净退出也会重新拉起，更容易把“程序主动退出”变成无休止循环。默认值是 no，表示 systemd 不自动重启。

第三环是RestartSec= 的间隔。它不是超时时间，而是一次退出后到下次重启前的等待。间隔过短时，程序还没等到依赖恢复就被再次拉起，也会快速消耗启动额度。官方当前文档给出的项目默认值是 100 毫秒，但发行版或单元配置可能覆盖它，生产环境仍应读取生效值。

第四环是启动速率限制。StartLimitIntervalSec= 定义统计窗口，StartLimitBurst= 定义窗口内允许的启动次数。超过额度后，即使 Restart= 仍然要求重启，管理器也会拒绝继续启动。这个限制是保护系统的断路器，而不是最初故障。

第五环是failed 状态。它是前面事件累积后的管理器状态。看到 start-limit-hit 时，应向前追查最早的进程退出和日志错误，不能把速率限制误判为应用的首要根因。

用日志还原退出码与信号

systemctl status 适合快速摘要，完整证据应回到 journal。先限定单元，再限定本次开机，避免被同名进程或历史启动记录干扰。如果服务刚刚失败，可以同时观察退出前的应用日志和 systemd 记录的主进程状态。

# 查看本次开机中该服务最近 100 条日志，保留完整行。
sudo journalctl -u demo.service -b --no-pager -n 100 -o short-precise

# 持续跟踪该服务，观察启动、退出和下一次重启是否形成循环。
sudo journalctl -u demo.service -f

# 只查看错误及以上级别，用于从大量业务日志中缩小范围。
sudo journalctl -u demo.service -b -p err --no-pager

判断时至少回答四个问题：主进程是主动退出还是被信号终止；错误发生在执行前、启动阶段还是运行阶段；每次失败信息是否一致；失败前是否存在依赖不可用、权限拒绝、配置解析或资源耗尽记录。若每次都在几十毫秒内以相同状态退出，通常应先查固定配置和执行条件；若运行一段时间后才失败，则更应关注负载、内存、外部依赖和应用内部异常。

不要只看最后一条 Start request repeated too quickly。它只说明启动请求在统计窗口内超过额度，真正有价值的应用错误通常出现在更早位置。必要时记录首次失败时间，再按时间窗口查询。

# 以首次失败时间为起点读取完整上下文，时间请替换为现场值。
sudo journalctl -u demo.service \
  --since "2026-10-07 04:00:00" \
  --until "2026-10-07 04:10:00" \
  --no-pager -o short-precise

核对真正生效的单元配置

systemd 单元可能同时来自发行版包、/etc/systemd/system 中的本地文件和一个或多个 Drop-In。直接打开某个猜测路径，容易漏掉覆盖项。先用 systemctl cat 查看合并后的文本来源，再读取主文件与 Drop-In 路径。

# 显示单元主文件及所有 Drop-In 内容，并标出每段来源路径。
sudo systemctl cat demo.service

# 查看主文件与 Drop-In 的实际路径，确认修改位置。
sudo systemctl show demo.service -p FragmentPath -p DropInPaths

# 再次读取关键生效参数，避免把文件文本误当成最终配置。
sudo systemctl show demo.service \
  -p Restart -p RestartUSec \
  -p StartLimitIntervalUSec -p StartLimitBurst

下面是一份偏保守的长期服务示例。它用 on-failure 处理异常退出，用 5 秒间隔避免紧密循环，并把 60 秒内最多 5 次启动作为断路器。参数不是通用答案，应结合服务启动成本、依赖恢复时间和业务恢复目标调整。

[Unit]
# 单元说明用于状态查看和审计记录。
Description=Demo worker
# 60 秒是启动次数的统计窗口。
StartLimitIntervalSec=60s
# 窗口内最多允许 5 次启动尝试。
StartLimitBurst=5

[Service]
# simple 适合前台持续运行且不自行 fork 的程序。
Type=simple
# 使用绝对路径，减少工作目录和 PATH 差异带来的问题。
ExecStart=/usr/local/bin/demo-worker
# 只在异常退出、异常信号或超时等失败条件下重启。
Restart=on-failure
# 失败后等待 5 秒，给依赖和资源留出恢复时间。
RestartSec=5s

若配置由软件包维护，优先通过 systemctl edit demo.service 创建 Drop-In，而不是直接修改供应商文件。升级软件包时，Drop-In 的本地意图更清晰，也便于审计和回滚。

按风险等级选择修复动作

如果服务会产生副作用，先执行 stop 可以暂时切断攻击路径式的故障放大。停止不会修复根因，但能保护数据库、队列或第三方接口。随后可使用与单元相同的用户、环境文件和工作目录手动运行程序，确认问题是否来自应用本身；这一步必须谨慎，避免在生产环境重复处理真实数据。

# 高风险循环可先停止服务，防止继续冲击下游依赖。
sudo systemctl stop demo.service

# 查看单元配置的运行用户、工作目录和环境文件来源。
sudo systemctl show demo.service \
  -p User -p Group -p WorkingDirectory -p EnvironmentFiles

Restart=always 适合极少数必须被持续保持的进程，但它会把退出码 0 的主动终止也变成重启。如果应用用正常退出表示“配置无任务”“已完成一次性工作”或“管理员请求停止”，就不应依赖 always。一次性任务更适合由 timer、path 或其他调度机制触发，而不是伪装成长驻服务。

修复配置后再清除速率计数

修改单元文件后，先让管理器重新加载配置。systemctl reset-failed 会清除单元的 failed 状态，同时重置启动速率限制计数和重启计数。正因为它会抹掉部分现场状态，所以必须在证据已经保存、根因已经修复后执行，而不是把它当作通用“解锁命令”。

# 重新加载单元文件和 Drop-In，使修改后的配置生效。
sudo systemctl daemon-reload

# 根因修复后再清除 failed 状态、启动速率计数和重启计数。
sudo systemctl reset-failed demo.service

# 启动服务，避免 restart 把“停止”和“启动”混成一个难以观察的动作。
sudo systemctl start demo.service

# 核对最终状态、结果和新的重启计数。
sudo systemctl show demo.service \
  -p ActiveState -p SubState -p Result \
  -p ExecMainCode -p ExecMainStatus -p NRestarts

恢复后不要只看到 active (running) 就结束。至少观察一个覆盖典型初始化和依赖交互的时间窗口，并验证业务探针、端口或任务消费是否正常。如果 NRestarts 再次增长，说明服务仍在退出；此时应回到退出证据，而不是重复 reset-failed。

留下可复盘的审计记录

一次完整记录应包含：单元名称、首次失败时间、Result、ExecMainCode、ExecMainStatus、修复前后的 NRestarts、主文件与 Drop-In 路径、关键参数生效值、应用日志摘要、修改内容和验证窗口。这样才能判断下次告警是同一根因复发，还是新的退出路径。

# 一次性导出关键生效属性，便于附到变更或故障记录中。
sudo systemctl show demo.service \
  -p FragmentPath -p DropInPaths \
  -p ActiveState -p SubState -p Result \
  -p ExecMainCode -p ExecMainStatus \
  -p Restart -p RestartUSec -p NRestarts \
  -p StartLimitIntervalUSec -p StartLimitBurst

如果故障涉及敏感环境变量、令牌或数据库连接串，审计记录只保留配置来源和错误类型，不要复制秘密值。故障排查需要证据完整性，但不应因为“方便复盘”制造新的凭据泄露风险。

验证清单

• 已保存首次失败附近的 journal，而不是只保存最后一条速率限制消息。
• 已读取 ExecMainCode、ExecMainStatus 与 Result，能说明进程如何结束。
• 已使用 systemctl cat 和 DropInPaths 确认配置来源。
• 已用 systemctl show 核对 Restart、RestartUSec 与启动速率参数的生效值。
• 已修复程序、权限、路径、环境或依赖根因，再执行 reset-failed。
• 恢复后 ActiveState=active、SubState=running，且观察期内 NRestarts 不再增长。
• 业务探针、端口、队列消费或核心请求已验证，而不仅是进程存在。

常见问题

为什么服务显示 start-limit-hit？

这表示启动请求在 StartLimitIntervalSec 统计窗口内超过 StartLimitBurst。它是 systemd 阻止故障继续放大的保护结果。应先查更早的退出码和日志，再决定是否需要调整速率参数。

可以直接把 StartLimitBurst 调得很大吗？

不建议把它作为第一修复动作。提高额度只会允许更多次启动，不能修复错误配置、权限、依赖或程序崩溃；如果启动有外部副作用，还可能扩大影响。

Restart=always 和 on-failure 怎么选？

长期服务通常优先评估 on-failure，因为正常退出不会被强制拉起。只有业务确实要求“无论退出原因都持续运行”，并且程序具备幂等启动与可靠停止语义时，才考虑 always。

reset-failed 会启动服务吗？

不会。它清除 failed 状态及相关计数，使单元重新具备启动条件；之后仍需单独执行 start。把清除状态和启动拆开，也更方便观察每个动作的结果。

归纳起来，systemd 重启循环的排查核心是“从结果向前追根因”：failed 和速率限制是管理器状态，Restart= 是恢复策略，进程退出码、信号和日志才是最早证据。先修根因，再恢复状态；先验证业务，再结束故障处理。