systemd ExecCondition 怎样在启动前做条件判断

把检查命令写在服务的 [Service] 段中，通过退出码表达条件即可：通常 0 继续，1–254 跳过后续启动命令且不标记服务失败，255 或异常退出则标记失败。ExecCondition 在 ExecStartPre 之前执行，适合“这次可以不运行”的判断，不适合把所有故障都包装成正常跳过。

官方地址：https://www.freedesktop.org/software/systemd/

下文用一个可选报表任务说明配置与排查方法。文件名、服务名均为示例；没有在本机部署、启动或生成运行截图。使用前应核对目标发行版的本地手册，ExecCondition 自 systemd 243 起提供。

先把继续、跳过和失败分开

这张表以没有额外改写成功退出码的常规配置为前提。若设置了 SuccessExitStatus，应一起阅读：被它认定为成功的退出码也允许继续。不要一边把 1 约定为“跳过”，一边又把 1 加入成功列表。

值班时最容易误判的是“没有 failed 就表示任务完成”。条件跳过可能恰恰意味着主任务完全没有执行。业务要求每次都必须出报表时，缺少必要输入更可能需要报错，而不是使用可选任务的跳过语义。

用最小单元表达可选运行条件

假设维护者只有在显式放置允许标记后才希望运行报表。下面是独立测试单元的示意，不应直接覆盖现有服务。主程序路径需要替换为你已经部署的真实程序，test 的绝对路径也要按本机安装位置确认。

[Unit]
Description=Optional report task

[Service]
# 标记存在才允许尝试启动；缺失时test返回1，表示本次跳过。
Type=oneshot
ExecCondition=/usr/bin/test -f /run/report-demo.allow
# 替换为自己的报表程序；条件满足并不保证主程序一定成功。
ExecStart=/usr/local/bin/report-demo

这里的标记仅表达允许意图，不证明输入完整、外部依赖可用或主程序已经完成。条件检查与主任务之间也可能发生变化，业务程序仍需在使用资源时处理错误，不能把启动前检查当成事务锁。

需要一个简单文件条件时，也可以评估单元层的 Condition 类指令。不过它与 ExecCondition 不是完全等价的执行机制，不宜为了减少一行配置就随意互换。本文示例的重点是命令退出码，而不是扩展到所有启动条件选项。

让检查脚本保留内部错误

单个 test 适合简单判断；一旦要区分“管理员尚未允许”和“检查输入已损坏”，应让脚本明确返回。下面脚本约定 1 是预期跳过，255 是检查错误，0 是允许继续。两个路径是独立示例，不代表系统已存在这些文件。

#!/bin/sh
# 没有允许标记属于正常跳过，不修改任何文件。
if [ ! -f /run/report-demo.allow ]; then
    printf '%s\n' 'skip: report task is not enabled' >&2
    exit 1
fi

# 一旦已允许执行，必要输入不可读就视为检查异常。
if [ ! -r /etc/report-demo/input.conf ]; then
    printf '%s\n' 'error: required input is not readable' >&2
    exit 255
fi

# 允许后续启动；主任务仍负责业务阶段的错误处理。
exit 0

若选用脚本，将 ExecCondition 指向已安装、可执行且由受信任维护者管理的脚本绝对路径，不要在单元行里直接拼接 shell 管道或重定向。systemd 的命令行解析不是完整 shell 语法。示例中的重定向位于 sh 脚本内部，不能原样挪到 ExecCondition 等号右侧当成 shell 命令链。

检查要短小、可结束，避免把常驻进程或无限等待放在条件里。尤其不要使用“任意错误都 exit 1”的包装：权限问题、脚本解释器问题和超时都应保留真实诊断线索。

按状态和日志判断是否执行主任务

维护者在自己的测试环境安装单元后，可以用以下只读入口获取配置和状态。以下查询不是本文已经执行的验证，也不包含伪造输出。

# 查看生效配置，注意是否有drop-in覆盖条件或成功退出码。
systemctl cat report-demo.service
# 查询加载状态、活动状态和最近结果，不能只看active一项。
systemctl show report-demo.service -p LoadState -p ActiveState -p SubState -p Result
# 查看本次启动相关日志；无权限时通过获授权的运维渠道读取。
journalctl -u report-demo.service -b -n 60 --no-pager

先确定单元是否正确加载，再看条件命令的退出说明，最后核对是否出现主程序的业务记录。若是 oneshot 且没有 RemainAfterExit，正常执行完也不会长期保持 active。因此 inactive 既不能单独证明失败，也不能单独证明条件跳过。

排障记录应至少包含生效配置、条件退出信息、服务结果和业务完成记录。主任务没有记录时，再判断它是被条件跳过、尚未执行还是启动失败，而不是马上反复重启。条件命令失败时也可能涉及 ExecStopPost，已有清理逻辑应按未启动主任务的情况设计，不能假定业务已经初始化完成。

恢复配置时保留条件语义

如果新条件误拦截任务，先恢复本次变更前保存的单元或对应 drop-in，再在维护窗口由有权限的人员重新加载配置并安排启动。不要为了“赶紧变绿”把检查一律改成返回 0，也不要删除整个服务目录。

回退要说明恢复的是哪一份条件和退出码约定。如果“缺失标记”本来属于正常跳过，监控应同时识别这个业务状态；若业务要求本轮必须执行，就应对缺失完成记录报警，而不仅订阅 failed。两者是业务契约不同，不是 systemd 状态定义矛盾。

整理上线前的判断清单

确认三个问题：什么情况允许不运行，什么情况必须失败，什么证据表示主任务完成。然后检查脚本的每条错误路径是否落入正确类别，并核对生效配置中没有 SuccessExitStatus 或命令前缀意外吞掉错误。先在测试单元分别覆盖允许、跳过和错误情形，再安排正式变更。

为什么退出 2 没有标记失败？在未被成功码规则改变的常规语义下，2 位于跳过范围。若它代表检查程序自身错误，应在受控脚本中明确映射为失败约定，而不是让监控猜测。

条件通过后服务还会失败吗？会。它只允许进入后续启动命令，不保证后续配置或业务逻辑成功。

可以用条件检查代替健康检查吗？不能。启动前的一次允许判断不证明运行中的持续健康，也不证明本次任务完成。

参考：systemd.service 官方手册；systemctl 官方手册；journalctl 官方手册。