systemd 怎样用 ConditionPathExists 控制服务启动条件

我在整理 systemd 服务配置时，最容易混在一起的不是语法，而是“这个服务现在不该启动”和“这个服务启动失败”两件事。ConditionPathExists= 解决的是前一种：在 unit 真正执行启动作业前检查路径，条件不满足就跳过本次启动，不把 unit 标成 failed。

官方文档：https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html

需要“配置文件存在才启动”时使用 ConditionPathExists=/绝对路径；需要“标记文件不存在才启动”时在路径前加 !。它是启动条件，不会自动建立依赖关系，也不负责服务崩溃后的重启。

先分清启动条件和依赖

这项能力的关键变化，是把“是否适用于当前机器”放在 unit 启动前判断。官方文档说明，条件在排队的启动作业实际执行时检查；多个普通条件同时存在时相当于逻辑 AND，条件失败通常只是跳过，unit 不会进入 failed。所以条件适合表达“没有配置就不用跑”“没有挂载点就跳过”这类环境开关。

第一次使用时，我会先写清楚三种职责：Condition... 决定是否适用，Requires= 与 After= 表达依赖和顺序，Restart= 处理进程退出后的重启。把它们混成一条配置，后面查看状态时很容易误判。

用 ConditionPathExists 控制单一路径

最常见的写法是把一个配置文件或目录作为服务启动前置条件：

[Unit]
Description=示例配置服务
# 只有配置文件存在时，systemd 才会尝试启动本服务
ConditionPathExists=/etc/example/app.yaml

[Service]
# 示例命令只表示服务入口，实际项目应替换为自己的程序
ExecStart=/usr/local/bin/example-server --config /etc/example/app.yaml

这里的路径应写成绝对路径。ConditionPathExists= 检查的不只是普通文件，也可以是目录、设备节点、FIFO 或 socket；符号链接会跟随，断开的符号链接不会被当作存在。若文件缺失，systemd 不是把服务判为故障，而是把这次启动条件判为不满足。

这很适合可选组件：配置包尚未安装时，服务保持干净状态；配置补齐后，再次启动或由上层启动作业触发即可重新判断。它不替代配置校验，如果文件存在但内容错误，仍应让程序自己报告配置错误。

用否定条件和 Glob 扩展开关

路径前加感叹号可以表达反向条件。例如，某个维护标记存在时暂不启动：

[Unit]
Description=维护标记不存在时启动
# ! 表示路径不存在时条件才成立
ConditionPathExists=!/run/example/maintenance.flag

# 至少有一个匹配项时才启动批处理服务
ConditionPathExistsGlob=/var/lib/example/ready.d/*.ok

ConditionPathExistsGlob= 与单路径检查的差别是，它判断 glob 是否至少匹配一个文件或目录。不要把 glob 当成“所有文件都存在”的断言；如果要求多个文件同时存在，直接写多个 ConditionPathExists=，让它们形成 AND。

多个条件也不会创建启动顺序。比如配置文件条件通过，并不代表数据库服务已经启动；那是 Requires=、Wants=、After= 等依赖或排序设置的职责。

用 systemd-analyze 做最小检查

我通常先用 systemd-analyze condition 检查表达式，再去看服务重启日志。官方命令会输出每条条件的结果以及合并后的 Conditions succeeded 或 failed：

# 直接判断配置文件是否满足启动条件
systemd-analyze condition 'ConditionPathExists=/etc/example/app.yaml'

# 判断“维护标记不存在”这一反向条件
systemd-analyze condition 'ConditionPathExists=!/run/example/maintenance.flag'

# 让 systemd 根据 unit 文件中的 Condition 与 Assert 一起判断
systemd-analyze condition --unit=example.service

如果条件失败，先检查路径、权限和符号链接目标，再决定是否需要修改 unit。重新加载 unit 文件时可以使用：

# 修改 unit 后让 systemd 重新读取配置；这里只是配置动作，不会自动启动服务
systemctl daemon-reload
# 在确认条件满足后再请求启动
systemctl start example.service

迁移时保留清晰的职责边界

从旧脚本迁移到 systemd 时，我会把“是否存在”留给 ConditionPathExists，把“必须拉起的服务”写进依赖，把“进程退出后怎么办”留给 Restart。这样排障路径是清楚的：条件失败看路径，依赖失败看 unit 关系，进程退出看服务日志和重启策略。

相关问题

ConditionPathExists 失败会让 systemd 报错吗？

它通常只会跳过这次启动，不会把 unit 移入 failed。若要把检查失败作为明确错误处理，应评估 AssertPathExists= 等断言语义。

条件通过后服务仍然没启动怎么办？

继续检查 unit 是否被 mask、依赖是否满足、ExecStart 是否可执行，以及程序自身的退出日志；不要只重复修改路径条件。

最后可以把判断压缩成一句话：路径决定 unit 是否适用，依赖决定它和谁一起启动，Restart 决定进程退出后的动作。先把三者拆开，ConditionPathExists 就会变成一个很稳定的配置开关。