systemd 怎样按退出码决定是否重启

systemd 里，Restart= 决定服务通常采用什么自动重启策略，而 RestartForceExitStatus= 用来补充一个更窄的规则：只要主服务进程以指定退出码、退出状态名或信号结束，就把这次退出纳入强制自动重启判断。它适合“某个退出状态代表需要重新拉起服务”的场景，不等于无条件重启所有失败。

本文只讨论 RestartForceExitStatus，示例把退出码 42 当成应用约定的可恢复状态。官方手册地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html。下面的图是静态结构说明图，不是实际运行截图。

RestartForceExitStatus 到底改变什么

最小理解可以拆成两层：Restart= 提供默认重启策略，RestartForceExitStatus=42 指定一个即使不符合默认判断、也要进入重启判断的退出状态。它们共同作用于服务的主进程，而不是把所有辅助命令的退出都改写成重启信号。

例如，服务平时使用 Restart=on-failure，应用在某个可恢复分支主动返回 42。把 42 写入 RestartForceExitStatus 后，systemd 会把这个状态作为强制重启条件处理。这里的关键不是“42 一定代表错误”，而是团队把这个数字约定成了一个明确的服务生命周期信号。

用退出码 42 写一个最小单元

把规则放在服务单元的 [Service] 段。下面的配置故意只保留与退出码重启有关的字段：

[Unit]
Description=示例服务：指定退出码触发重启

[Service]
# 让普通失败继续按 on-failure 的默认规则判断
Restart=on-failure
# 只有主服务进程返回 42 时额外强制进入重启判断
RestartForceExitStatus=42
# 示例程序由部署环境提供，这里只表达服务单元的调用关系
ExecStart=/usr/local/bin/demo-worker

[Install]
WantedBy=multi-user.target

把文件保存到例如 /etc/systemd/system/demo-worker.service 后，先让管理器重新读取单元，再查看解析后的配置：

# 中文注释：重新读取 unit 文件，不会自动启动服务
sudo systemctl daemon-reload

# 中文注释：查看最终合并后的 Restart 相关配置
systemctl cat demo-worker.service
systemctl show demo-worker.service \
  --property=Restart,RestartForceExitStatus,RestartPreventExitStatus

如果服务程序返回 42，重点观察的是主进程的退出状态与后续重启判断是否符合预期。不要把“配置被 daemon-reload 读取”误认为“服务已经按新规则运行”，需要在一次受控的服务生命周期中观察状态变化。

数字、状态名和信号名怎么选

该选项的参数格式与 RestartPreventExitStatus= 相似，可以写数字终止状态、状态名称或信号名称，多个值用空格分隔。工程上建议优先选择团队已经登记的状态名；如果应用协议明确使用自定义数字，则把数字及其含义写在服务说明或运维手册中。

[Service]
# 中文注释：多个值用空格分隔，表示这些主进程状态都属于强制重启集合
RestartForceExitStatus=42 143 SIGABRT

上例表达的是三个独立匹配项：数字 42、数字 143 和信号名 SIGABRT。不要把数字写成带有不确定含义的“魔法值”；如果状态来自脚本或多个语言实现，统一约定退出状态比单纯增加匹配项更容易维护。

同一选项可以出现多次，列表会合并；如果需要在 drop-in 中清空之前继承的值，可以把它赋为空字符串，再重新声明最终集合：

[Service]
# 中文注释：先清空上层 unit 继承的强制重启状态
RestartForceExitStatus=
# 中文注释：再声明当前服务真正保留的退出状态
RestartForceExitStatus=42

不要把三个边界混在一起

第一，匹配对象是主服务进程。官方说明强调，这类退出状态设置只针对主进程，也就是由 ExecStart= 启动的进程，或由服务类型、PID 文件等配置确定的主进程。ExecStartPre=、ExecStartPost=、ExecStop=、ExecStopPost= 和 ExecReload= 的退出不能直接用这个选项改造成主进程的强制重启条件。

第二，它和禁止重启规则存在决策关系。RestartPreventExitStatus= 是针对指定状态禁止自动重启；RestartForceExitStatus= 是针对指定状态强制进入自动重启判断。两者不要在同一个状态上同时配置，否则读配置的人很难判断实际意图，应该在单元设计阶段消除重叠。

第三，Type=oneshot 有特殊限制。对于 oneshot 服务，成功退出本身会阻止自动重启，无论对应成功状态是否写在 RestartForceExitStatus 中。需要一次性任务执行完就结束时，不要把这个选项当作绕过 oneshot 语义的开关。

配置后怎样判断方向对不对

排查时先看配置，再看服务状态，最后看日志，顺序越短越不容易被旧日志干扰。下面的命令只用于观察 systemd 当前记录，不会替你修改退出码约定：

# 中文注释：确认 unit 文件中的原始声明和 drop-in 位置
systemctl cat demo-worker.service

# 中文注释：确认管理器解析出的重启相关属性
systemctl show demo-worker.service \
  --property=Type,ExecMainCode,ExecMainStatus,Restart,RestartForceExitStatus

# 中文注释：按当前启动周期查看主进程退出与重启相关日志
journalctl -u demo-worker.service -b --no-pager

可以按下面的表格解释结果：

如果只是修改了 unit 文件，先执行 daemon-reload；如果服务已经在运行，是否需要手动重启取决于你的变更窗口和发布策略。不要用一次手工 systemctl restart 代替对目标退出状态的观察，因为手工重启并不能证明 RestartForceExitStatus 命中了。

什么时候值得使用

这个选项适合把应用内部的某个“需要重新拉起”的终止状态映射到 systemd 的生命周期管理中，例如配置已加载但进程需要由外部管理器重新创建，或者某个受控退出分支需要走统一的服务恢复策略。它的收益是把规则写在 unit 层，运维人员能在不读完整业务代码的情况下看懂触发条件。

它的代价也很明确：退出码语义成为应用与部署配置之间的契约。应用改了退出码、supervisor 改了启动方式，或者主进程识别发生变化，都可能让规则失效。因此建议只维护少量、命名清楚的状态，并在发布清单中同时记录 Restart=、RestartForceExitStatus= 和服务类型。

常见问题

RestartForceExitStatus 能不能替代 Restart？

不能。它是对指定退出状态的补充规则，通常要和一个明确的 Restart= 策略一起阅读。若要表达完整的服务恢复策略，应先决定普通失败、正常退出和特定状态分别怎么处理。

写了退出码但服务没有重启怎么办？

先确认退出的是主服务进程，再用 systemctl cat 和 systemctl show 确认配置已被管理器加载，最后查看同一启动周期的 journal。若服务是 Type=oneshot，还要单独检查是否触发了成功退出限制。

可以同时写多个退出状态吗？

可以，使用空格分隔。为了让配置可维护，建议每个状态都对应一条团队约定，并避免与 RestartPreventExitStatus 交叉使用。

一句话总结：RestartForceExitStatus 不是“无条件重启”开关，而是把主服务进程的一组明确退出状态接入既有的 systemd 自动重启判断。把退出码契约、服务类型和重启策略放在一起维护，排查时先看最终配置，再看主进程状态，最后对照日志。