systemd Condition 与 Assert 失败有什么区别

最直接的区别是：Condition...= 不满足时，systemd 会跳过这次启动；Assert...= 不满足时，systemd 会让本次启动作业失败并记录明显错误。容易误解的一点是，官方文档明确说明两者都不会直接把单元状态改成 failed；Assert 失败的是启动作业，而不是把单元永久标成故障。

一、先按前置条件是否必须满足来选

两类检查都写在 [Unit] 段，并在排队的 start job 即将执行时求值。多个普通条件默认按 AND 组合；只有全部满足，服务才继续进入后续启动阶段。

二、Condition 适合“这台机器不需要启动”

下面的采集服务只有在数据目录存在时才有意义。目录不存在并不代表系统坏了，因此选择 Condition：条件为假时不会执行 ExecStart，也不会制造一条必须处理的失败告警。

[Unit]
Description=Optional metrics exporter
# 目录不存在时跳过，不把它当成运维故障
ConditionPathExists=/srv/metrics

[Service]
Type=simple
ExecStart=/usr/local/bin/metrics-exporter

这种写法适合镜像在多种机器上复用：有采集目录的节点启动服务，没有该目录的节点自然跳过。不要为了“看起来都启动了”而创建空目录，否则会掩盖环境差异。

三、Assert 适合“缺少它就必须报错”

数据库迁移任务没有凭据文件就不应继续。此时使用 Assert，可以让发起启动的一方立刻看到作业失败，日志也会明确记录断言未满足。

[Unit]
Description=Database migration worker
# 缺少关键配置时让本次启动作业失败
AssertPathExists=/etc/myapp/db.conf

[Service]
Type=oneshot
ExecStart=/usr/local/bin/db-migrate

Assert 的用途是把“管理员必须处理的前置条件”变成显式错误。它依然不是健康检查：服务启动后配置被删除，Assert 不会持续监控，也不会自动停止已经运行的进程。

四、排查时同时看作业结果、单元状态与依赖

# 修改 unit 后重新加载配置
sudo systemctl daemon-reload

# 发起一次启动，观察命令是否报告作业失败
sudo systemctl start example.service

# 查看当前单元状态与最近的条件提示
systemctl status example.service

# 查看本次开机以来的完整服务日志
journalctl -u example.service -b

还要特别注意 Requires=：被依赖单元因为 Condition 不满足而跳过，并不会自动让依赖方的启动作业失败。官方也说明，Condition 和 Assert 不适合用来“条件化”依赖图。若目标是约束两个单元的生命周期，应重新设计 Requires=、After= 或更强的 BindsTo= 关系，而不是只把 Condition 换成 Assert。

配置完成后可以对照 systemd.unit 官方说明确认当前系统版本支持的具体检查项。

相关问题

Assert 不满足后，为什么 systemctl status 不一定显示 failed？

因为失败的是排队的启动作业，断言本身不触发单元状态变化。应结合启动命令返回、状态输出中的断言提示和 journal 日志判断。

可以用 ExecStartPre 代替 Assert 吗？

可以执行自定义检查，但语义不同。简单的路径、架构、虚拟化和能力判断优先使用内置 Assert；只有必须运行脚本或命令才能判断时，才考虑 ExecCondition 或 ExecStartPre，并明确处理退出码。