Linux systemd ExecStartPre 怎样在启动前检查配置文件

我在给 Linux 服务加配置校验时，最容易写错的地方不是检查命令本身，而是把检查放到了主进程启动以后。ExecStartPre= 的职责正好相反：它会在 ExecStart= 之前执行，所有没有忽略错误的检查成功后，主进程才有机会启动。

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

下面用一个“配置文件必须存在且非空”的场景说明写法。示例是静态配置说明，不代表在本文环境中实际运行；真正部署前要把路径、用户和检查工具换成自己的服务约束。

先记住 ExecStartPre 的失败规则

在 service 单元里，ExecStartPre= 可以出现多次，systemd 会按单元文件中的顺序串行执行。只要某一行返回非零退出码，并且命令没有使用忽略失败的 - 前缀，后续准备命令和 ExecStart= 都不会继续，服务会进入失败状态。

这让它适合做“启动闸门”：配置不存在、权限不对或格式检查失败时，宁可让服务不启动，也不要让主进程带着半截配置运行。需要注意，ExecStartPre 不是守护进程托管位置；它派生出的进程会在下一个服务进程运行前被清理，因此不要把长时间运行的进程放在这里。

用绝对路径把配置检查放到启动前

最小单元可以这样组织。这里用 test -s 表示“文件存在且大小大于零”，并用一个独立的 ExecStartPre= 让意图清楚地留在 service 文件里。

# [Unit] 只描述服务与系统目标之间的关系
[Unit]
Description=Demo agent with config preflight
After=network-online.target

[Service]
# 配置文件不存在或为空时，阻止主进程启动
ExecStartPre=/usr/bin/test -s /etc/demo-agent/config.toml
# 主进程使用同一份配置文件
ExecStart=/usr/local/bin/demo-agent --config /etc/demo-agent/config.toml
# 让可执行文件无法启动时也能被 systemctl start 感知
Type=exec

[Install]
# 允许把服务挂到多用户启动目标
WantedBy=multi-user.target

命令的第一个词必须是可执行文件名或绝对路径，后面的内容才是参数。ExecStartPre=/usr/bin/test -s ... 不是由 shell 解释的管道表达式；如果需要管道、重定向或条件组合，应显式调用一个确定的 shell，并把脚本本身当作被检查的对象管理。

编辑单元文件后，先让 systemd 重新读取它，再处理服务。下面的命令用于查看解析后的字段和失败日志，文章只展示操作路径，不在本机执行：

# 读取 unit 文件与覆盖片段，确认实际加载的来源
systemctl cat demo-agent.service
# 只查看 systemd 解析出的准备命令和主命令
systemctl show demo-agent.service -p ExecStartPre -p ExecStart
# 修改 unit 文件后重新载入配置
sudo systemctl daemon-reload
# 配置不满足时，启动请求会在 ExecStartPre 处失败
sudo systemctl restart demo-agent.service
# 查看准备命令返回失败的上下文
sudo journalctl -u demo-agent.service -n 50 --no-pager

检查失败时，三种语义不要混用

生产里我通常先决定“检查失败是不是服务失败”，再选择写法。硬性配置检查用普通的 ExecStartPre=；可选检查才考虑忽略错误；如果条件不满足只是跳过本次启动而不应把 unit 标成 failed，则应看 ExecCondition=。

ExecCondition= 与单元级 Condition... 也不是一回事：前者参与激活过程，后者会在激活前阻止单元进入启动事务。不要只因为“都能做条件判断”就随意替换。

部署前的三个排查重点

第一，检查命令要站在服务的执行身份和文件系统视角下理解。test 能否读取文件，和登录用户在交互式 shell 中能否读取文件，不一定相同；User=、目录权限以及根目录隔离都会影响结果。

第二，不要把需要持续运行的 watcher、代理或后台任务塞进 ExecStartPre。它的生命周期只服务于启动前准备；持续进程应由 ExecStart= 管理，启动完成信号则交给合适的 Type= 或通知机制。

第三，修改后先确认 systemd 读到的字段，再看日志。systemctl cat 适合发现 drop-in 覆盖，systemctl show 适合确认解析结果，journalctl 则用来把“检查命令返回失败”与“主程序自己启动失败”区分开。

相关问题

ExecStartPre 可以写多行吗？可以，systemd 会按顺序串行执行；任何未忽略的失败都会阻止后续命令。

ExecStartPre 能直接写管道吗？不能把 shell 管道语法当作普通参数解析；需要管道时显式指定 shell 或独立脚本。

为什么检查成功但服务仍然启动失败？ExecStartPre 只说明准备阶段通过，二进制路径、User=、Type= 或主程序自身仍可能失败，应继续查看 ExecStart= 对应的日志。

把 ExecStartPre 当成短小、明确、可失败的启动前闸门，systemd 单元就能在“配置不完整”和“服务已经对外运行”之间建立清晰边界。