systemd服务崩溃自动重启，Restart参数全套生产模

systemd 是绝大多数 Linux 发行版默认的初始化系统，
服务一旦崩溃，
它可以用 Restart 参数自动拉起进程。生产环境里，
服务文件写错一个参数，
轻则无法启动，
重则陷入不断重启的循环。 这篇文章会从零讲清 Restart 的取值逻辑，
给出一套可以直接拿用的生产模板，
并告诉你如何验证重启是否真的生效。

动手前先确认 systemd 版本

多数 CentOS 7、Ubuntu 16.04 之后的系统都自带 systemd，但不同版本对启动频率限制的写法有差异。
先在服务器上执行：

systemd --version

如果版本号大于等于 229，启动次数限制（StartLimitIntervalSec、StartLimitBurst）要写在 [Unit] 段；
如果版本较老，则写在 [Service] 段。这是最容易踩的坑，先确认版本再抄模板。

Restart 参数到底怎么选

[Service] 段里的 Restart= 控制服务退出后的行为。
默认值是 no，也就是不自动重启。
生产常用取值如下：

• on-failure：仅当进程异常退出（非零退出码、被信号杀死、超时等）时重启。适合绝大多数守护进程。
• always：无论正常退出还是异常退出，都无条件重启。适合需要 7×24 常驻的进程，但配置错误或启动依赖缺失时会疯狂重启。
• on-abnormal：只在被信号、超时等异常情况才重启，正常 exit 不重启。适合那些可能自行退出但你不希望它被拉起的服务。

同时建议配合 RestartSec= 设置重启间隔，例如 RestartSec=3s，避免崩溃后瞬间拉起导致 CPU 飙升。

一套生产可用的服务模板

新建或替换 /etc/systemd/system/myapp.service，内容如下：

[Unit]
Description=My Application Service
After=network.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=simple
User=www-data
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=on-failure
RestartSec=3s
TimeoutStopSec=30s

[Install]
WantedBy=multi-user.target

这里 StartLimitIntervalSec=300 和 StartLimitBurst=5 表示5 分钟内最多启动 5 次，超过就放弃并报 failed。
防止服务因启动必崩溃而把服务器资源耗尽。

保存后执行：

systemctl daemon-reload
systemctl enable myapp
systemctl start myapp

注意：每次修改 /etc/systemd/system/ 下的文件后，必须执行 daemon-reload，否则 systemd 仍按旧配置运行。

怎么确定重启真的生效了

先手动杀掉服务进程，看它会不会被拉起。
假设你的进程 PID 是 12345：

kill -9 12345
sleep 5
systemctl status myapp

如果状态显示 active (running)，且 Main PID 变了，说明自动重启已生效。
另外可以查看日志：

journalctl -u myapp -n 50

里面会记录 Main process exited, code=killed 和 Scheduled restart job 之类的信息。

容易踩的坑和常见疑问

• 写错退出码判断：Restart=always 会让服务因正常 stop 也被拉起来，如果你手动 systemctl stop 想停服，它会立刻又启动。这时应该改成 on-failure，或在停止前先 systemctl mask。
• 启动循环后 journal 被刷爆：加上 StartLimitIntervalSec 和 StartLimitBurst 能限制拉起次数，但日志仍可能大量写入。建议给服务设置独立的 LogRateLimit 或使用 journald 的限流配置。
• 明明重启了却还是连不上：检查服务是否依赖网络、数据库等外部条件，After= 只决定了启动顺序，不保证依赖可用。建议在应用里增加健康检查或等待重试。

如果你刚接手一套存量服务，想临时看下它会崩多少次，可以执行 systemctl show myapp -p NRestarts 查看累计重启次数。
需要调整参数时，务必先在测试机验证，再推到生产环境。

按照上面的模板和验证步骤，你就能把服务崩溃后的自动拉起稳稳掌握。
如果你的服务本身存在逻辑问题，自动重启只是兜底手段，还是要从日志里定位根因，避免陷入“拉起-崩溃-再拉起”的循环。