Linux ConditionPathExists 条件服务为何显示 skipped：unit 状态与日志验收

有一类 Linux 服务故障很容易被误判：systemctl status 里没有红色 failed 报错，服务却完全没跑起来，日志里还能看到条件不满足就被跳过的提示。最常见的原因就是 unit 配置里写了 ConditionPathExists=，但对应的配置文件、挂载文件夹或者生成标记还没在预期路径里出现。

为什么服务没启动，却不是 failed 状态

假设一台日志采集机上的 metrics-agent.service 依赖 /etc/metrics-agent/agent.yml。管理员执行对应查询命令后：

systemctl status metrics-agent.service

如果看到类似“条件检查未满足，启动被跳过”的状态，第一反应不要马上执行 systemctl restart。这个结果通常说明 systemd 完全按照 unit 文件写的前置条件做了正常判断，真正的问题是被检查的路径没有在服务启动的时间点出现。

先确认实际加载的 ConditionPathExists 配置

不要只盯着代码仓库里的模板文件核对配置。系统很可能通过 drop-in 片段覆盖了同一个 unit 的原有参数，当前实际加载的内容要交给 systemd 自己展示：

systemctl cat metrics-agent.service
systemctl show metrics-agent.service -p FragmentPath -p DropInPaths -p Conditions

重点核对三处信息：主 unit 文件来自哪个存储路径，是否存在 /etc/systemd/systemm/metrics-agent.service.d/ 下的自定义覆盖文件，以及 Conditions 属性里记录了哪些生效的判断条件。如果 unit 文件中出现：

[Unit]
Description=Metrics agent
ConditionPathExists=/etc/metrics-agent/agent.yml

[Service]
Type=simple
启动命令沿用现有服务配置
Restart=on-failure

这里的逻辑是“对应路径存在才允许进入后续的服务启动流程”。它不会校验文件内部的 YAML 格式是否合法，也不会自动帮你创建缺失的文件夹；路径存在但内部内容损坏时，错误信息还是要靠主进程自己的日志来暴露。

用三条证据判断到底缺了什么

第一条证据直接核对路径本身的状态：

test -e /etc/metrics-agent/agent.yml && echo present || echo missing
stat /etc/metrics-agent/agent.yml

第二条证据查看 unit 的当前运行状态：

systemctl show metrics-agent.service \
  -p ActiveState -p SubState -p Result -p Conditions

如果路径不存在，常见结果是 unit 根本没有进入 active 状态，Result 就明确反映了条件被跳过的结果；不要把这个状态和进程运行后崩溃的情况混为一谈。第三条证据提取本次启动的完整记录：

journalctl -u metrics-agent.service -b --no-pager -n 80

把这三条结果放在一起交叉核对，比单独盯住一行 status 输出要可靠得多。

修复路径后怎样让服务重新判断条件

如果只是补齐了缺失的配置文件，不一定需要重载 unit；但如果改动了 unit 本身文件或者 drop-in 片段，应该先让 systemd 重新读取全量配置：

sudo systemctl daemon-reload
sudo systemctl start metrics-agent.service
systemctl is-active metrics-agent.service
systemctl status metrics-agent.service --no-pager

如果配置文件来自网络盘或者开机时才挂载的外接磁盘，单纯把 ConditionPathExists 改成更宽松的条件并不能彻底解决启动竞态问题。更稳妥的做法是把挂载单元写入 RequiresMountsFor=，或者把配置生成任务和目标服务建立明确的依赖关系，保证目标路径完全就绪之后再触发服务启动。

别把条件判断改成启动前检查命令

两者的语义完全不同。ConditionPathExists 适合表达“环境不满足就不需要启动服务”，条件为假时不会把 unit 标记为失败状态；写在启动阶段的检查命令则是在服务启动流程内部运行，命令返回非零值时通常会直接判定为启动失败。如果监控规则只盯 failed，前者可能不会触发任何告警，后者则会直接进入失败告警链路。

生产环境里可以为“条件未满足”的情况补一条独立监控：定期读取 systemctl show 的运行状态，并把配置文件、挂载状态和最近一次系统日志作为告警上下文。这样既保留了 systemd 自带的幂等启动语义，也不会让“被跳过”变成没人处理的静默故障。

相关问题

ConditionPathExists 会检查文件内容吗？

不会。它只做路径存在性校验；配置格式、权限和内容合法性的检查，仍由服务进程或者单独的前置检查命令负责。

改完 unit 文件为什么状态没变化？

修改 unit 或者 drop-in 片段后需要执行 systemctl daemon-reload，再重新启动或重启目标 unit，否则 systemd 可能还在使用内存里缓存的旧配置。

条件不满足时应该用 start 还是 restart？

先补齐路径并确认文件内容可读，再用 start 触发一次条件重判；当前已经有进程在运行时才考虑 restart，避免打断完全无关的正常运行服务。

排查这类问题的关键不是把 skipped 当成故障，而是确认 systemd 实际加载了哪条条件规则、条件检查的路径是否真的存在，以及修复操作后 unit 是否真的进入了预期的 active 状态。三类证据可以把“服务没起来”拆成可逐一验证的路径问题、配置问题或者依赖顺序问题。