systemd RestartSec 怎样影响服务重启节奏

我第一次调整 systemd 服务的重启配置时，最容易混淆的是“多久再试一次”和“最多允许试几次”。RestartSec=只决定服务退出后、下一次自动启动前要等多久；它不会改变什么情况算失败，也不会取消启动速率限制。对连续失败的长驻服务，通常要把 Restart=、固定等待或退避参数，以及 StartLimit* 放在同一张配置图里理解。

官方文档：https://freedesktop.org/software/systemd/man/latest/systemd.service.html

想让服务每次失败后固定等 5 秒再启动，就设置 Restart=on-failure 和 RestartSec=5s；如果失败会持续发生，使用 RestartSteps= 与 RestartMaxDelaySec= 把等待逐步拉长；如果启动次数在窗口内过密，仍要检查 StartLimitIntervalSec= 与 StartLimitBurst=。

RestartSec 控制的是哪一段等待

把一次自动恢复拆开看，顺序并不复杂：服务进程退出，systemd 根据 Restart= 判断是否安排自动重启，随后等待 RestartSec= 指定的时间，最后再次进入启动动作。这个参数是“重启间隔”，不是启动超时，也不是失败次数上限。

官方文档给出的默认 RestartSec= 是 100ms，也接受无单位秒数或类似 5min 20s 的时间跨度。生产服务如果仍使用很短的等待，失败进程可能在短时间内反复拉起，日志和依赖连接都会被快速刷屏；把它调大只能拉开尝试间隔，不能修复服务本身的启动错误。

[Service]
# 只在异常退出、启动失败或超时等失败场景自动重启
Restart=on-failure
# 服务退出后，下一次自动启动前固定等待 5 秒
RestartSec=5s
# 真正的业务程序入口；这里不写重试逻辑
ExecStart=/usr/local/bin/demo-worker

这里还有一个常被忽略的边界：管理员主动执行 systemctl stop 或 systemctl restart 时，systemd 不会把这次由管理动作造成的退出当作需要再次自动重启的失败。也就是说，Restart=on-failure 不是“无论谁停掉都立刻拉起”。

固定等待和指数退避怎样取舍

固定等待适合故障恢复时间稳定、服务失败后很快就能重新依赖外部资源的场景。比如依赖短暂网络抖动的消费者，可以先用 3 到 10 秒的固定值，让服务有机会重新建立连接。对一直无法启动的服务，固定等待会让每一次失败都以相同频率发生，这时我更倾向于使用退避配置。

RestartSteps= 和 RestartMaxDelaySec= 配合后，systemd 会从 RestartSec= 开始逐步增加自动重启间隔。官方示例是 RestartSec=10s、RestartSteps=4、RestartMaxDelaySec=160s，得到 10、20、40、80、160 秒，达到上限后继续保持上限。这个能力在 systemd 254 中加入；如果目标系统更旧，不能把它当成所有发行版都支持的通用字段。

[Service]
# 失败后先等待 5 秒，避免瞬时故障立刻形成高频重启
Restart=on-failure
RestartSec=5s
# 让连续失败的等待逐步增加，分四个指数阶段
RestartSteps=4
# 将自动重启等待封顶在 120 秒
RestartMaxDelaySec=120s
# 多个实例同时失败时，再叠加 0 到 10 秒的随机延迟
RestartRandomizedDelaySec=10s

这里要分清三个参数的职责：RestartSec=是起点，RestartSteps=决定向上增加的阶段数，RestartMaxDelaySec=决定最长等待。RestartRandomizedDelaySec=是在已有等待基础上额外加入随机延迟，适合许多相同实例同时失败、又不希望它们在同一时刻重启的场景。它们都只改变重启节奏，不能替代对 ExecStart、环境变量、权限和依赖服务的排查。

RestartSec 与 StartLimit 怎样共同限制失败循环

我遇到过“已经把 RestartSec 调到 30 秒，服务还是显示 start-limit-hit”的情况。原因是两个层面在同时工作：重启参数控制两次尝试之间的等待，StartLimitIntervalSec= 与 StartLimitBurst= 控制一个时间窗口里允许出现多少次启动。后者不仅作用于自动重启，也适用于手动启动等其他启动来源。

因此，调整 RestartSec 后仍然被限流并不矛盾：只要历史启动尝试已经超过窗口允许次数，systemd 就不会继续按重启逻辑尝试。等待窗口过去后，可以再次手动启动；在确认服务已经修复、需要清掉失败计数时，systemctl reset-failed 才是对应的管理动作。

一份可回退的长驻服务配置

对普通后台 worker，我会先从简单配置开始，不一上来就堆叠所有参数。先确认服务本身的退出条件，再决定是否需要指数退避；如果使用了 systemd 254 之后才提供的退避项，要把目标发行版和 systemd 版本写进变更记录。

[Unit]
# 仅声明服务依赖，避免把重启策略和网络准备混在一起
After=network-online.target

[Service]
# 长驻服务异常退出时自动恢复
Restart=on-failure
# 先用可解释的固定等待作为基线
RestartSec=5s
# 连续失败时逐步降低重启频率
RestartSteps=3
RestartMaxDelaySec=60s
# 同类实例错峰恢复，避免同时争抢依赖资源
RestartRandomizedDelaySec=5s
ExecStart=/usr/local/bin/demo-worker

[Install]
# 允许按需启用该服务
WantedBy=multi-user.target

这份配置的关键不在于“数值越大越稳”，而在于每个值都能解释：5 秒是正常短暂抖动的缓冲，60 秒是持续故障的上限，随机延迟是错峰手段。若服务是一次性任务，不要直接套用长驻服务的 Restart=on-failure；先确认任务的幂等性和重复执行代价。

用展开配置和日志判断节奏

排查时我会先看 systemd 实际展开后的属性，而不是只盯着某一个 unit 文件。因为 drop-in、模板实例和管理器默认值都可能参与最终配置。下面的命令是排障示例，输出应由读者在自己的机器上获取，本文没有把任何命令输出当作运行截图。

# 查看 systemd 实际采用的重启与启动限流属性
systemctl show demo-worker.service --property=Restart,RestartUSec,RestartSteps,RestartMaxDelayUSec,RestartRandomizedDelayUSec,StartLimitIntervalUSec,StartLimitBurst

# 按带日期时间的格式查看最近失败和启动记录，比较相邻时间点
journalctl -u demo-worker.service -o short-iso --since "10 min ago"

# 只有在确认故障已修复、需要人工恢复时才清理失败计数
systemctl reset-failed demo-worker.service

如果 RestartUSec 与文件里的 RestartSec 不一致，优先相信展开后的属性，再回头检查 drop-in 和模板实例；如果相邻启动时间差接近固定值，说明固定等待可能正在生效；如果时间差逐步变长，则要继续检查退避项；如果最后出现 start-limit-hit，就把视线移到启动速率限制，而不是继续无条件增大 RestartSec。

几个容易混淆的问题

RestartSec 越大，服务越可靠吗？

不一定。它只能降低失败重启的频率，给外部依赖和运维人员留出时间；值过大则会拉长真正恢复时间。先根据故障恢复窗口设置，再用日志观察是否需要退避。

RestartSec 能代替 StartLimit 吗？

不能。前者是两次自动启动之间的等待，后者是时间窗口内的启动速率限制。一个服务可以有较长的 RestartSec，同时仍然因为窗口内历史启动尝试过多而被限制。

什么时候只用固定等待？

短暂网络抖动、依赖服务很快恢复、重复启动代价较低时，固定等待更容易解释和排障。只有连续失败会持续占用资源或产生噪声时，才有必要加入指数退避和随机错峰。

修改 unit 后为什么节奏没变化？

检查是否重新加载了 unit 配置、是否修改了正确的实例文件，以及 systemctl show 展开的属性是否已经变化。若属性已变化但仍被限流，继续查看 StartLimit* 与日志中的启动结果。

总结一下：先用 Restart=定义哪些失败值得自动恢复，再用 RestartSec=设置最小等待；连续失败时用 RestartSteps= 和 RestartMaxDelaySec=逐步放慢；最后用 StartLimit*控制启动风暴。把这三层分开，服务重启节奏就不再是“反复改一个秒数碰运气”。