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

程序执行、应用就绪和响应健康是三项独立检查。图中示例配置允许 60 秒内启动五次，快速失败后延迟五秒。再次尝试达到限制时，自动重启停止。较慢失败可能始终低于速率限制。单纯等到间隔结束不会排定新尝试；修复原因后应有意识地启动，或先清除计数器再启动。保存第一次失败日志，并核验就绪状态和健康响应。
按配置窗口统计启动次数。启动速率限制可以停止快速反复重启，但不能证明健康，也不限制生命周期重试总数。

捕获启动失败

对长驻进程，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 清除计数器后启动。在隔离服务中测试可执行文件缺失与快速崩溃，并保存第一次失败日志，不要只留下最后的“达到启动限制”消息。

来源