Linux systemd After 和 Wants 怎样配合启动依赖

在 systemd 中，After=demo-helper.service 只声明顺序，不会单独请求启动 demo-helper；Wants=demo-helper.service 会在启动当前单元时尝试一并拉起它，却不独自规定先后。需要“尝试拉起辅助服务，并等待它的启动作业结束”时，通常在当前服务的 [Unit] 中同时写 Wants 和 After，指向同一个辅助单元。

这里的等待不等于辅助服务一定成功，更不等于数据库端口或远端接口已经可用。官方文档：https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html；服务启动完成的判定还涉及 Type，见 https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html。实际机器应同时参考本地 man 文档。

只有After却没拉起依赖时先分清两种关系

设 demo-consumer.service 使用一个可选辅助单元 demo-helper.service。观察到 consumer 启动了，helper 却没启动，先不要增加 sleep。若只声明 After，这个现象本身并不违背配置：排序关系只有在相关作业存在时才有作用，它不会凭空创建 helper 的启动请求。

表格只比较这两项指令；真实系统可能从 target、其他单元、隐式依赖和 drop-in 获得额外关系，因此不能仅凭主文件中的一行推断整张依赖图。

先看管理器实际加载的配置

# 查看主文件及相关覆盖片段，确认修改对象和名称。
systemctl cat demo-consumer.service
# 对照管理器当前识别的依赖，而不只看磁盘上的主文件。
systemctl show demo-consumer.service -p FragmentPath -p DropInPaths -p Wants -p After
# 分别查看两个单元的加载状态与运行状态。
systemctl show demo-helper.service demo-consumer.service -p Id -p LoadState -p ActiveState -p SubState -p Result

这些是供读者在目标 Linux 机器使用的只读排查命令，本文未执行。After 和 Wants 的列表不必只有一个值；重点是是否包含预期的精确单元名，以及 helper 是否能被加载。若出现 not-found 或 masked，应先解决单元存在性或屏蔽状态，不要把弱依赖失败直接归结为顺序错误。

对于用户级服务，需在一致的用户会话范围内使用 systemctl --user；不要把系统级与用户级管理器的配置、状态混在一起比对。修改磁盘文件后若未重新加载，cat 所见与管理器持有的关系可能不同。

把两条配置放到同一个Unit段

下面仅供隔离测试机复现，不能覆盖已有业务单元。先确认 demo-helper.service 和 demo-consumer.service 这两个名称未被占用，并确认 /usr/bin/true、/usr/bin/echo 是目标发行版的实际可执行路径；不一致时按本机路径调整。分别在 /etc/systemd/system 下创建对应文件。

demo-helper.service：

[Unit]
Description=Dependency demonstration helper

[Service]
# oneshot 以命令退出作为此例启动完成的依据。
Type=oneshot
ExecStart=/usr/bin/true
RemainAfterExit=yes

demo-consumer.service：

[Unit]
Description=Dependency demonstration consumer
# 拉入同一个辅助单元，并分别声明排序约束。
Wants=demo-helper.service
After=demo-helper.service

[Service]
# 不连接业务系统，只写一条示例消息。
Type=oneshot
ExecStart=/usr/bin/echo demo-consumer
RemainAfterExit=yes

Wants 与 After 都是 [Unit] 指令。文件中的排列先后不会让它们变成依次执行的命令。这里不写 [Install]，因为演示只手动启动 consumer，不需要设置开机启用关系。

# 仅在确认两个演示名称未占用、文件已保存的隔离测试机执行。
sudo systemctl daemon-reload
# 启动 consumer，helper 由 Wants 尝试拉入，不要求先 enable。
sudo systemctl start demo-consumer.service
# 查看本次启动状态和日志，不据图示假定已经成功。
systemctl status demo-helper.service demo-consumer.service --no-pager
journalctl -b -u demo-helper.service -u demo-consumer.service --no-pager

预期判断是：两个演示单元均能成功加载；当 helper 的 true 命令成功退出后，consumer 的启动命令才能开始。由于 RemainAfterExit=yes，两者正常结束后预计保持 active (exited)。本文没有实际启动服务，不提供伪造状态输出；若本机结果不同，应以真实状态和日志为依据。

区分启动完成与业务就绪

本例 helper 为 Type=oneshot，启动完成与它的命令退出关联，适合说明排序语义。但换成常驻程序后，完成点取决于服务类型。例如 Type=simple 不会等待应用内部初始化完毕，不能仅凭 After 就认定监听端口已开放。Type=notify 也需要程序真正实现就绪通知，不能只改 Type 字段就获得健康检查。

Wants 是弱拉起关系。helper 启动失败并不要求 consumer 同样失败；加上 After 只把失败的启动作业也纳入排序等待，不把失败转换成成功门槛。如果业务绝不允许依赖启动失败后继续，应单独评估更强依赖与应用就绪契约，不能靠 Wants 加更多延时模拟。

按症状收束排查范围

helper 完全没被请求时，先看 Wants 中是否含它；两者同时开始时，检查 After 是否指向同名单元，以及是否有反向排序、其他依赖或加载错误。发生依赖循环时应读取 systemd 的实际诊断并消除冲突，不要叠加更多互相矛盾的 After。

consumer 已开始但 helper 仍未提供业务功能时，应回到 Type 与应用日志，而不是继续修改拉起关系。只关心谁被拉入，就查 Wants；关心作业排序，就查 After；关心业务连接能否成功，则已经超出这两个指令本身。

如果只改错了新加的 drop-in，可在保留原配置的前提下只回退那一处变更，再 daemon-reload；不要用清空整个单元目录的方式“恢复”。本例设置了 RemainAfterExit，重复 start 已 active 的演示单元不会强制重新执行命令，复现新一轮启动需在隔离环境先停止两者再开始，不能据此判断配置失效。

常见问题与配置选择

只写 Wants 为什么不能保证 helper 更早完成？

Wants 解决拉起关系，不解决排序；若系统里没有其他排序约束，不能假定它先结束。需要排序时单独写 After。

helper 没有 enable 还能被拉起吗？

可以，只要它能加载且允许启动。enable 处理安装关系，手动 start 与依赖拉起不以它已启用为必要条件；WantedBy 也不能和 [Unit] 中的 Wants 当成同一个位置的配置。

Wants 会在 helper 崩溃后持续拉起它吗？

不会仅凭该关系就持续保活。本文只讨论启动时的弱拉起与顺序，不把它扩展成故障恢复或健康监控方案。

排查时保留两个问题即可：helper 是否被请求启动，以及双方作业之间是否有顺序约束。Wants 与 After 各回答一个问题，业务就绪和失败策略则应另行明确。