Linux systemd 怎样用 RestartSec 控制重启节奏

我第一次认真调 RestartSec，并不是因为它“不会重启”，而是因为一个服务重启得太勤快：进程启动后马上退出，systemd 立刻再次拉起，日志很快被重复的启动信息淹没。后来我发现，RestartSec 解决的是“每次重启之间等多久”，而不是“要不要重启”。真正可维护的配置，至少要把 Restart、RestartSec 和启动限流分开看。

官方地址：https://www.freedesktop.org/software/systemd/man/262/systemd.service.html

如果服务只在异常退出时恢复，可以用 Restart=on-failure 决定触发条件，再用 RestartSec=5s 增加重启前等待；当服务仍然连续失败时，还要用 StartLimitIntervalSec 和 StartLimitBurst 控制一个时间窗口内最多允许多少次启动。

先把 RestartSec 放回重启链路

把一行配置单独拿出来，很容易误解。systemd 只有在 Restart= 允许重启时，才会在服务退出或超时后走自动恢复路径；RestartSec= 位于“判断需要重启”和“下一次启动”之间。

这个位置决定了它的适用力：它能给依赖服务、端口释放、临时文件清理和外部资源恢复留出时间，但不能修复程序本身的配置错误。程序每次启动都因为同一个错误退出时，单纯把 5 秒改成 60 秒，只是把下一次失败推迟了。

用最小 service 配置控制失败重启

对长期运行的后台服务，我通常先从“异常才恢复、等待几秒、启动命令保持单一”开始。下面的片段故意保持克制，方便把每个参数的职责看清楚。

[Unit]
Description=订单同步服务
After=network-online.target

[Service]
Type=simple
# 只有非正常退出或启动超时等失败场景才自动重启
Restart=on-failure
# 每次自动重启前先等待 5 秒，让依赖和资源有机会恢复
RestartSec=5s
ExecStart=/opt/order-sync/bin/order-sync

[Install]
WantedBy=multi-user.target

这里最重要的不是“5 秒”这个数字，而是先确认 Restart=on-failure 的语义。手工执行 systemctl stop 导致的停止，不应被当成程序故障再次拉起；若希望连正常退出也重启，才考虑 Restart=always，但它更容易把一次有意退出变成循环。

修改 unit 文件后，先让 systemd 重新读取配置，再查看服务状态：

# 重新读取 unit 文件，并启动服务
sudo systemctl daemon-reload
sudo systemctl restart order-sync.service

# 查看当前状态、最近一次退出原因和重启计数
systemctl status order-sync.service --no-pager

# 只查看本次启动以来的服务日志
journalctl -u order-sync.service -b --no-pager

把等待时间和启动限流分开判断

我曾经把“服务每秒重启很多次”和“服务被 systemd 暂停重启”当成同一个问题处理，结果只会反复改 RestartSec。实际上，RestartSec 是每次自动重启前的间隔；StartLimitIntervalSec 与 StartLimitBurst 约束的是时间窗口里的启动次数，而且手工启动也会计入这个限制。

例如，下面的组合表达的是“每次失败等 5 秒，10 秒内最多尝试 3 次”，而不是“10 秒后无论如何都自动恢复”。当失败原因仍在时，达到限制后 systemd 会停止继续自动尝试，管理员可以先查清根因，再决定是否清理失败状态。

[Unit]
# 10 秒是启动次数的统计窗口，不是每次重启等待
StartLimitIntervalSec=10s
# 统计窗口内最多允许 3 次启动尝试
StartLimitBurst=3

[Service]
# 只对失败退出触发自动恢复
Restart=on-failure
# 每次自动恢复前等待 5 秒
RestartSec=5s

重启过快与重启过慢，分别意味着什么

重启过快通常表现为日志中连续出现短间隔的启动和退出。常见原因是配置文件路径错误、端口已经被占用、权限不足，或者服务依赖尚未就绪。此时增加一点 RestartSec 可以降低抖动，但不能替代对第一条真实错误日志的处理。

重启过慢则可能让上游请求等待太久。若服务启动只需要几百毫秒，而 RestartSec=2min，故障恢复窗口就会被人为拉长。我的经验是先按依赖恢复速度设置一个小的固定等待，再用启动限流阻止故障服务无限撞击系统，而不是一开始就用很大的间隔掩盖问题。

还有一个容易忽略的边界：RestartSec 不等于应用内部的重试退避。应用连接数据库的重试、systemd 对进程的重启、负载均衡器的摘除与恢复，属于三层不同的节奏。把它们都设成“每 5 秒一次”，并不会自动得到协调的恢复策略。

用状态和日志复查配置意图

调整参数后，我会按“配置是否被读取—服务为什么退出—是否达到启动限流”三步复查。下面的命令只读取状态和日志，不改变 unit 文件：

# 显示 systemd 实际加载到的关键字段
systemctl show order-sync.service \
  -p Restart -p RestartUSec -p NRestarts -p Result

# 查看最近一次启动失败前后的日志
journalctl -u order-sync.service -n 80 --no-pager

# 确认服务是否进入 failed，以及最近一次失败结果
systemctl is-failed order-sync.service

不同发行版或 systemd 版本展示字段可能略有差异，但判断思路不变：如果 Restart 没有按预期加载，先处理 unit 覆盖文件和 daemon-reload；如果 NRestarts 持续增加，说明自动重启路径在工作；如果服务进入 failed 且不再自动尝试，再检查启动限流和日志中的首次故障。

在确认原因、修复配置或依赖后，可以清理失败状态并重新启动：

# 仅在已处理失败原因后清空失败计数，再重新启动服务
sudo systemctl reset-failed order-sync.service
sudo systemctl start order-sync.service

按场景选择一组可维护参数

最后我会用三个问题做选择：服务启动成本高不高、依赖恢复需要多久、故障时是否可能产生资源争用。一个轻量的无状态 worker，可以从 Restart=on-failure 加几秒 RestartSec 开始；启动要加载大模型、挂载网络存储或等待数据库的服务，应把等待时间和依赖顺序一起设计；会快速失败的程序，则必须同时设置启动限流并保留清晰日志。

• 只想让异常退出自动恢复：先看 Restart=on-failure。
• 想让下一次启动避开短暂资源冲突：调整 RestartSec。
• 想防止服务反复撞击系统：设置 StartLimitIntervalSec 与 StartLimitBurst。
• 看到服务被限流：先查首次失败原因，再按需执行 reset-failed。

我对这组参数的结论是：RestartSec 是节奏旋钮，不是故障修复按钮。把触发条件、等待时间和启动上限拆开，配置才更容易解释，日志也更容易与实际行为对应。

相关问题

RestartSec 不写时默认等多久？

官方 systemd.service 文档给出的默认值是 100ms。生产服务通常不应只依赖默认值，最好根据依赖恢复和故障影响明确写出配置。

RestartSec 能阻止服务无限重启吗？

不能。它只改变每次自动重启前的等待；启动次数上限应由 StartLimitIntervalSec 和 StartLimitBurst 配合处理。

为什么 systemctl stop 后服务没有自动拉起？

这是正常的预期：由 systemd 主动停止服务通常不被当作需要自动恢复的故障退出。应先确认停止动作是否来自人工、部署脚本或其它 unit。