关键服务应选Restart=on-failure而非always，因其仅在退出码非0、信号终止、启动或看门狗超时时重启；须配RestartSec和StartLimit防雪崩，并确保Type匹配实际启动行为。

关键服务需要的不是“能重启”，而是“重启得合理、停得及时、查得清楚”。systemd原生就支持这套闭环机制，核心是三件事：精准触发重启、主动限制频率、明确暴露异常。不需要额外脚本，也不依赖外部监控。

重启策略选 on-failure，不是 always

对数据库、消息队列、API网关等有状态或资源敏感的关键服务，Restart=on-failure 是更安全的默认选择。它只在以下情况触发重启：

• 进程退出码非 0（如程序报错退出）
• 被信号强制终止（如 SIGSEGV 段错误、SIGKILL 被 OOM killer 杀掉）
• 启动超时（由 TimeoutStartSec 控制）
• 看门狗超时（若启用 WatchdogSec）

避免用 Restart=always，否则正常 reload 或运维主动 stop 都会立刻拉起，干扰操作节奏，也掩盖了本该人工介入的计划性停机。

必须配 RestartSec 和 StartLimit 防雪崩

光设 Restart 不够，连续崩溃可能拖垮系统。要在同一 [Service] 块中同步配置：

• RestartSec=10：每次重启前强制等待 10 秒，给依赖服务（如数据库、缓存）恢复时间，也避免 CPU 空转
• StartLimitIntervalSec=60：以 60 秒为一个统计窗口
• StartLimitBurst=3：该窗口内最多重启 3 次；超过即标记为 start-limit-hit，systemd 停止自动拉起，必须人工 systemctl reset-failed 服务名 后才能继续

这个组合相当于给服务加了一道“熔断器”——既保可用，又防失控。

Type 匹配真实启动行为，否则 Restart 失效

systemd 能否检测到崩溃，取决于它是否真正在追踪主进程。确认 Type= 设置与服务实际行为一致：

• Type=simple（默认）：适合前台运行的 Go/Python 服务，systemd 启动后即认为就绪，崩溃可捕获
• Type=forking：适用于传统 daemon（如 nginx、redis），必须配合 PIDFile= 指向正确路径，否则 systemd 无法识别主进程是否存活
• Type=notify：推荐用于需初始化完成才对外提供服务的场景（如 Spring Boot、FastAPI），服务启动后调用 sd_notify("READY=1") 主动通知就绪，systemd 才开始计时和监控

如果 Type 错配，比如把 notify 型服务写成 simple，systemd 可能在服务真正就绪前就判定“启动成功”，后续崩溃也无法准确感知。

验证与日常可观测性不能少

配置完别只信 status 显示“active”，要主动验证闭环是否真实有效：

• 模拟崩溃：sudo systemctl kill --signal=SIGSEGV 服务名，观察是否在 RestartSec 秒后拉起
• 查重启记录：systemctl show 服务名 | grep -E "(Restarts|StartLimit)"，确认 Restarts 计数递增且未触发 limit-hit
• 盯日志流：journalctl -u 服务名 -n 30 -f，重点看 Started / Starting / Failed with result 的交替节奏
• 设环境变量或日志重定向（如 StandardError=file:/var/log/服务名-error.log），确保错误上下文不丢失

真正的自愈能力，是故障发生时你还没收到告警，服务已恢复；而故障持续时，你又能第一时间从日志和计数里定位根因。