重启策略需要一个速率限制

Mon, 03 Aug 2026 00:00:00 +0000

对长驻服务来说，自动重启很有用，但无界的循环会把一个清晰的失败变成一个嘈杂的失败。单元文件应同时描述正常进程生命周期与可接受的恢复量。

按配置窗口统计启动次数。启动速率限制可以停止快速反复重启，但不能证明健康，也不限制生命周期重试总数。

捕获启动失败

对长驻进程，Type=exec 能在启动时暴露配置程序执行失败，而不是把一次 fork 当成功。把它与显式的 ExecStart 以及能完成工作所需最小权限的 User 搭配使用。

[Unit]
Description=Example foreground site service
StartLimitIntervalSec=60s
StartLimitBurst=5

[Service]
Type=exec
User=site
ExecStart=/srv/site/bin/server
Restart=on-failure
RestartSec=5s

Type=exec 确认程序已执行，并不确认应用已就绪。程序应保持前台运行；应用支持显式就绪通知时可用 Type=notify。Restart=on-failure 是恢复策略，不是健康检查。如果进程在提供错误响应的同时保持存活，systemd 不会知道站点坏了；外部冒烟测试仍有其职责。

限制循环

Systemd 通过 StartLimitIntervalSec= 与 StartLimitBurst= 应用启动速率限制。这两个指令放在 [Unit]，RestartSec 放在 [Service]。示例允许 60 秒内启动五次；快速失败之间只有五秒重启延迟，因此可能达到限制。更长延迟可能让循环一直低于该速率：这并不是整个生命周期的重试次数预算。应按预期故障模式选择限制。当达到限制时，日志里应包含区分"重启成功"与"重复失败后放弃"所需的证据。

在获准使用的测试主机上安装或修改单元后，先验证文件、重载管理器并检查有效配置，再重启。下列命令会改变服务状态，可能中断流量：

systemd-analyze verify /etc/systemd/system/example.service
systemctl daemon-reload
systemctl cat example.service
systemctl show example.service -p Restart -p RestartUSec \
 -p StartLimitIntervalUSec -p StartLimitBurst
systemctl restart example.service
systemctl status --no-pager example.service
journalctl -u example.service -n 80 --no-pager

不要用重启策略掩盖缺失文件、无效权限或糟糕的环境。先修复第一次失败，再测试恢复路径。

启动限制停止自动重启后，单纯等到间隔结束不会自动排定下一次尝试。修复原因后，可等待间隔结束再启动，或有意识地用 systemctl reset-failed example.service 清除计数器后启动。在隔离服务中测试可执行文件缺失与快速崩溃，并保存第一次失败日志，不要只留下最后的“达到启动限制”消息。

来源

systemd.service，服务类型、重启与启动速率限制器，已核验 2026-08-03。
systemd.unit，通用单元段与 drop-in 语义，已核验 2026-08-03。
systemd.service upstream manual (v257)，Type=exec/oneshot、就绪、激活超时与重启语义，已核验 2026-10-15。
systemd.unit upstream manual (v257)，启动限制所属配置段、速率窗口与 reset-failed 行为，已核验 2026-10-15。

可靠的默认行为胜过聪明的恢复

Mon, 20 Jul 2026 00:00:00 +0000

小服务往往在正常路径被充分理解之前，就先累积了恢复逻辑。每一次重试、备用端点与兼容分支，都增加了必须被观察和测试的一个状态。

让常见路径可见。先判断并限制重试，再恢复到保留的已知良好状态，避免选择半成品副本。

让常见路径变得无聊

一个有用的默认行为是明确的、易于检视的、且可安全重复的。对静态站点，可以简单到：

构建自固定的工具链。
检查生成的 HTML、资源与完整的待发布目录。
发布该目录，再把公共响应与它核对。
保留上一个目录以便回滚。

这段序列不如多阶段部署系统炫目，但它的状态可见。当某处失败时，运维者能回答：问题在源码、构建、复制还是 Web 服务器。

只对可限定范围的操作重试

当故障可能是瞬时的、且重复操作不会改变其预期效果时，重试才有用。幂等不等于每次响应或附带日志都相同；响应丢失后，第一次尝试可能早已成功。从源站下载可能可安全重试；数据库迁移则未必。把每个错误都看作可重试的，会掩盖需要关注的边界。

当重试适当时，记录尝试次数与最终原因。类似"发布失败：校验和不匹配"的日志条目，比一串静默重试后跟一个笼统超时更有可操作性。

偏好单一权威状态

配置、运行时状态与文档应一致地说明哪个目录是活动的、哪条命令产生它。如果一个发布可以被不同的人复制到三条不同路径，恢复就变成了猜谜。

对静态部署，一份简短的发布记录就够了：

release: 2026-07-20
source: git commit <commit-id>
builder: Hugo 0.165.0
output: public/
verification: links + headers + checksums

占位符 commit ID 应按设计在发布时解析，而不是在文档里杜撰。

恢复应回到已知状态

当恢复把服务带回最后一个已知良好目录，而不是在几个半成品替代品之间选择时，恢复最容易。保留上一次输出直到新输出通过检查，再按保留策略移除旧副本。

目标不是消除失败，而是把失败缩小到能解释、把恢复缩小到能信任。

同时限制重试次数与总耗时。多个客户端可能一起重试时，使用带随机抖动的退避，并避免每一层都重试。权限错误与确定性的无效输入需要修正，而不是更长的重试循环。

来源

RFC 9110 — HTTP Semantics，9.2.2 节关于幂等方法与重试，已核验 2026-07-20。
静态网站发布检查清单，本地配套资源。
AWS Builders’ Library: Timeouts, retries, and backoff with jitter，重试放大、有界重试预算、退避与随机抖动，已核验 2026-10-15。

Reliability · XB 现场笔记