Linux systemd识别 ExecStartPre 失败导致的未启动状态的实现方法

systemd 服务显示“未启动”或反复进入 failed，先不要急着修改 ExecStart=。如果日志里出现 ExecStartPre=... status=1/FAILURE，根因通常在前置命令：它没有成功退出，所以 systemd 不会继续执行主启动命令。处理方法是先确认失败的那一行，再决定该检查必须阻断启动，还是本来就允许失败的清理动作。

从 unit 状态确认失败发生在 ExecStartPre

先看 unit 的当前状态。重点不是只看最后一行“failed”，而是找出 Process: 行中带有 ExecStartPre 的命令和退出码。

# 查看摘要，定位失败的前置命令和退出状态
sudo systemctl status demo-api.service --no-pager

# 查看本次启动的完整日志，避免只凭状态摘要猜原因
sudo journalctl -u demo-api.service -b --no-pager -n 80

# 查看 systemd 合并后的 unit 内容，确认实际生效的配置
sudo systemctl cat demo-api.service

例如日志显示 ExecStartPre=/usr/bin/test -s /etc/demo-api/config.yaml (code=exited, status=1/FAILURE)，它只说明配置文件不存在、为空，或当前服务上下文无法读取；它还不能直接证明主程序本身有问题。因为前置检查已经失败，ExecStart=/usr/local/bin/demo-api 根本没有机会运行。

把前置检查写成可解释的严格门槛

如果配置、目录、权限或依赖是主服务运行的必要条件，就让检查失败。命令使用绝对路径，检查动作保持短小，并让每个检查对应一个清晰的错误日志。

[Unit]
Description=Demo API service
After=network-online.target

[Service]
Type=simple
# 配置为空时直接阻止主进程启动，避免服务带着半成品配置运行
ExecStartPre=/usr/bin/test -s /etc/demo-api/config.yaml
# 目录不存在或权限不正确时，让启动失败尽早暴露
ExecStartPre=/usr/bin/test -d /var/lib/demo-api
# 前置检查全部成功后才启动长期运行的主进程
ExecStart=/usr/local/bin/demo-api --config /etc/demo-api/config.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

修改 unit 后要先让管理器重新读取文件，再重启服务。daemon-reload 只刷新配置，不等于服务已经按新配置运行；状态判断应放在 restart 之后。

# 重新读取 unit 文件，避免继续使用旧配置
sudo systemctl daemon-reload

# 重启并触发新的前置检查
sudo systemctl restart demo-api.service

# 用简洁状态确认主进程是否真正进入运行态
sudo systemctl is-active demo-api.service

按容错边界处理可忽略的前置命令

systemd 允许在可执行文件路径前加 -，表示该命令的非零退出不再阻断启动。例如删除“可能不存在”的旧临时文件时，失败可以被视为无影响：

[Service]
# 旧缓存没有就算了，清理失败不应阻止主服务启动
ExecStartPre=-/usr/bin/rm -f /run/demo-api/old.sock
# 端口、配置和运行目录仍是硬门槛，不能静默忽略
ExecStartPre=/usr/bin/test -s /etc/demo-api/config.yaml
ExecStart=/usr/local/bin/demo-api --config /etc/demo-api/config.yaml

- 不是“修复失败”的开关，而是改变失败语义。把它加在 test、迁移脚本或权限检查前面，会让 systemd 继续启动，最后可能得到一个看似 active、实际上无法提供服务的进程。长期运行的守护进程也不应放在 ExecStartPre= 中，前置阶段结束后 systemd 会清理由这些命令派生的进程。

用验证清单收敛修改后的状态判断

最后用下面的顺序收口：先 systemctl cat 确认配置，再执行 daemon-reload、restart，随后同时看 status 和 journalctl。只有当主进程按预期运行，并且日志不再出现前置失败，才算真正解决。

相关问题

ExecStartPre 失败时 ExecStart 会继续执行吗？

默认不会。未加 - 的前置命令失败会停止后续启动链；只有显式容忍该失败，后续命令才会继续。

为什么手动执行检查命令成功，systemd 里却失败？

两者可能使用不同用户、工作目录、环境变量和文件权限。优先用 systemctl cat 确认命令，再从日志核对服务上下文，不要只复制交互式 shell 的结果。

可以用 ExecStartPre 启动一个常驻脚本吗？

不建议。前置命令用于短时准备和检查；常驻进程应放入独立 service 或主 ExecStart=，让 systemd 正确跟踪生命周期。