Linux systemd Restart=on-failure 为何不重启手动停止服务

给服务写了 Restart=on-failure，然后执行 systemctl stop demo.service，发现它没有自己回来，这是正常行为。这个配置关注的是服务异常退出、被异常信号终止或操作超时；如果停止动作本身是 systemd 按管理员请求执行的，systemd 会把它当作有意停止，不再创建自动重启。

官方资料：https://www.freedesktop.org/software/systemd/

先判断“谁让服务停下来的”：如果是 systemctl stop、依赖事务或系统关机，优先按人工控制处理；如果是进程非零退出、崩溃、超时或 watchdog 失败，Restart=on-failure 才可能介入。想恢复手动停止的服务，应明确执行 systemctl start 或 systemctl restart。

为什么手动停止不会触发 Restart=on-failure

Restart= 判断的是服务进程结束的原因，不是“只要服务不在 active 就启动”。在 on-failure 模式下，非零退出、未被视为正常的信号、启动或停止超时，以及 watchdog 超时，都属于可能的恢复场景。

但 systemctl stop 是管理员提交给 systemd 的停止作业。systemd 会主动结束服务进程，并记录这次停止由管理器操作产生；如果随后仍按失败逻辑重启，管理员就无法可靠地维护停机窗口、发布窗口或故障隔离状态。因此，服务被 systemd 主动停止时，自动重启逻辑会被抑制。

异常退出与手动停止怎么区分

不要只看 ActiveState=inactive。它只能说明当前没有运行，不能说明为什么停止。排查时先看单元摘要，再把主进程退出字段与本次启动日志放到同一时间点比较：

# 查看当前状态、结果和主进程退出信息
systemctl show demo.service \
  -p ActiveState -p SubState -p Result \
  -p ExecMainCode -p ExecMainStatus

# 查看本次启动以来的服务日志，确认停止前最后一条原因
journalctl -u demo.service -b --no-pager -n 80

如果日志显示管理员执行了 stop，或状态变化与发布脚本、依赖事务同时发生，就不要把它归类为故障。若 Result=exit-code、主进程返回非零，或者日志出现崩溃与超时，则继续检查 ExecStart、环境变量、依赖服务和资源限制。

服务单元怎样写才符合自动恢复预期

长时间运行的服务可以先从一个小而明确的单元开始。RestartSec 给失败后的再次启动留出缓冲，启动限流则防止配置错误导致快速重启循环：

[Unit]
Description=示例后台服务
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/demo-server
# 只在异常退出、超时等失败结果下尝试恢复
Restart=on-failure
# 避免进程刚退出就立刻再次占用资源
RestartSec=5s
# 限制短时间内的启动次数，便于暴露真正根因
StartLimitIntervalSec=60s
StartLimitBurst=5

[Install]
WantedBy=multi-user.target

这里不要用 Restart=always 来“修复”手动停止问题。它同样不能改变管理员明确停止的语义，却可能让正常退出的程序再次启动。若服务需要在某个维护脚本中恢复，脚本应显式调用 systemctl start demo.service，并把停机和恢复写入自己的变更记录。

已经停掉的服务如何安全恢复

确认停机是误操作或维护窗口已结束后，使用 start 让单元进入运行态；服务原本仍处于运行但需要重载进程时，才使用 restart。修改 unit 文件后先执行 daemon-reload，再按需启动：

# 重新读取 unit 文件，避免沿用旧配置
systemctl daemon-reload

# 手动停止后的明确恢复动作
systemctl start demo.service

# 检查恢复结果和最近日志
systemctl status demo.service --no-pager
journalctl -u demo.service -n 40 --no-pager

若启动失败，先看 systemctl status 的失败原因和日志，不要连续执行多次 restart 掩盖启动限流。达到 StartLimitBurst 后，systemd 可能暂时不再自动尝试；修好配置后再用 systemctl reset-failed demo.service 清理失败状态并重新启动。

常见问题

把 Restart=on-failure 改成 always 能自动拉起手动停止吗？

不能。由 systemd 执行的停止操作仍然不会按普通失败处理；需要恢复时应由运维脚本或管理员明确调用 start/restart。

服务显示 inactive 就代表它崩溃了吗？

不是。inactive 只描述当前状态，可能来自正常停止、依赖停止、关机或进程异常退出。结合 Result、主进程退出字段和 journalctl 日志判断。

为什么配置了 Restart=on-failure 还是没有重启？

除了手动停止，还要检查服务是否是 Type=oneshot、是否命中 RestartPreventExitStatus、是否触发启动限流，以及实际退出的是不是 systemd 追踪的主进程。

总结

Restart=on-failure 的重点是“失败后恢复”，不是“服务离开 active 就强行启动”。把人工停止、依赖事务、正常退出与真正故障分开记录，再用状态字段和日志复核，自动恢复策略才不会和维护操作互相打架。