systemd自动重启需按服务特性选策略、配熔断、控节奏：restart=on-failure最常用，always适用于不应正常退出的模型服务，restartsec建议轻量服务3–5秒、模型服务10–30秒，必须配合startlimitintervalsec和startlimitburst防雪崩，并通过日志落盘与健康检查补全可观测闭环。
systemd的自动重启不是“一开就灵”的开关，而是需要按服务特性选策略、配熔断、控节奏的一套协同机制。光写Restart=always可能让崩溃服务反复拉起，拖垮系统；不设限制又可能错过故障窗口。关键在匹配退出行为、设置合理间隔、加上启动频次兜底。
选对Restart策略，避免误重启
服务退出原因不同，重启逻辑也该不同：
- on-failure：最常用。只在进程非零退出码、被信号终止或超时时重启，适合Nginx、MySQL等常规服务
- always：不管怎么退都重启，适合模型服务（如gte-base-zh、Ostrakon-VL-8B），因为它们本就不该“正常退出”
-
on-abnormal：排除主动调用
exit(0)的场景，适合有明确生命周期控制的后台任务 - no：调试期或一次性脚本用，防止干扰排查
RestartSec不是越短越好
等待时间太短（比如1秒），可能撞上资源未释放、端口被占、磁盘IO卡顿等问题，导致重启链式失败；太长（比如60秒）又影响恢复速度。实际建议：
- 轻量服务（如Fish Speech-1.5 WebUI）：3–5秒
- 模型加载型服务（如vLLM推理、xinference启动）：10–30秒，留足模型加载和依赖初始化时间
- 带数据库或网络依赖的服务：可设为15秒，并配合
After=network-online.target确保网络就绪
必须加StartLimit防雪崩
没限流的自动重启就像没刹车的车——服务持续崩溃时会高频拉起进程，耗尽内存/CPU，甚至压垮整个系统。两个参数要一起配：
- StartLimitIntervalSec=60：滚动统计窗口（单位秒）
- StartLimitBurst=5：窗口内最多允许启动5次
超出后systemd会暂停重启并标记start-limit-hit，这时你需要查日志而不是等它自己恢复。S-UI和Hermes Agent配置里都明确写了这组参数，就是为防这类雪崩。
日志+状态反馈闭环不能少
自动重启只是动作，可观测才是运维基础：
- 用
StandardOutput=file:/path/log.out和StandardError=file:/path/log.err把输出落盘，比journal更易归档和分析 - 搭配
SyslogIdentifier=xxx统一日志标识，方便grep或ELK采集 - 健康检查脚本（如curl -f http://localhost:port/health）可单独用cron每分钟跑一次，失败则发告警，弥补systemd“只管进程不死、不管服务可用”的盲区
