直接结论：用systemd配置服务自动重启，核心是修改[service]段的restart=on-failure（推荐）和restartsec=5，再执行systemctl daemon-reload生效；需配合startlimitintervalsec=60与startlimitburst=3防雪崩，并确保type=匹配进程模型，最后用systemctl show验证参数加载。
直接结论：用 systemd 配置服务自动重启，核心是改 [Service] 段里的 Restart= 和 RestartSec=，再 systemctl daemon-reload 生效。其他方案（supervisor、crontab）只在特定场景下才值得考虑。
怎么确认服务已由 systemd 管理
别猜，直接查。运行 systemctl status <service-name></service-name>，如果返回类似 Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)，说明它走的是 systemd 流程。如果报 Unit nginx.service could not be found，那它可能还是旧式 /etc/init.d/ 脚本，得先迁移到 systemd 或换方案。
常见误区：以为 systemctl enable 就等于“能自动重启”——其实它只管开机自启，崩溃后是否拉起，完全取决于 Restart= 设置。
Restart= 值选哪个？别无脑填 always
Restart=always 看起来省心，但实际容易掩盖真实问题：比如配置文件路径写错、权限不足、端口被占，导致服务每次启动都立刻退出，然后 systemd 无限循环重启，日志刷屏，还可能拖垮系统。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
Restart=on-failure：最稳妥的选择。只在进程非零退出、被信号终止（SIGKILL除外）、超时或 watchdog 失败时重启 —— 这覆盖了绝大多数意外崩溃场景 -
Restart=on-abnormal：仅对信号终止（不含SIGTERM）和超时生效，调试时有用，生产环境少用 -
Restart=no：默认值，啥都不干；Restart=always：真要选它，务必配合日志和健康检查，否则等于埋雷
必须配的配套参数：RestartSec 和 StartLimit*
光设 Restart= 不够，没加延迟和频控，系统可能被反复拉起打满 CPU。
-
RestartSec=5：两次重启之间至少等 5 秒。小于 1 秒容易触发 systemd 的 rate limit，服务会被锁死 -
StartLimitIntervalSec=60和StartLimitBurst=3：默认 60 秒内最多启动 3 次，超了就拒绝后续启动 —— 这不是 bug，是保护机制。若服务确实需要高频重启（比如短时任务），得显式调大，不能删掉 - 别漏掉
Type=simple或Type=forking：Java/Python 启动脚本通常用Type=simple；如果程序自己 fork 成 daemon（如老版本 Redis），得改成Type=forking，否则 systemd 会误判进程已退出
改完配置后为什么没生效？三个高频卡点
常见现象：改完 .service 文件，systemctl restart 也不拉起，或者 Restart= 像没写一样。
- 没运行
sudo systemctl daemon-reload：这是硬性前提，不 reload，systemd 完全读不到新配置 - 路径写错或权限不对：检查
ExecStart=里的二进制路径是否存在、是否可执行（chmod +x），尤其注意用绝对路径，别信$PATH - 依赖没写对：服务卡在
activating (start)，八成是After=或Wants=缺失。比如 Web 服务要等网络就绪，就得加After=network-online.target和Wants=network-online.target
验证是否生效，别翻长日志，直接跑：systemctl show <service-name> | grep -E "(Restart|RestartSec|StartLimit)"</service-name>，输出里有对应字段才算落进去了。
