Linux systemctl list-dependencies 只看已加载单元的依赖边界

排查 systemd 服务依赖时，systemctl list-dependencies 给出的不是磁盘上所有 unit 文件的全量关系图，而是 service manager 当前已经加载到内存中的依赖视图。换句话说，命令结果为空或少了某个单元，不一定表示依赖不存在，先确认目标 unit 是否被当前 manager 认识，再解释关系。

官方地址：https://freedesktop.org/software/systemd/man/latest/systemctl.html

先确认“存在”与“已加载”不是一回事

一个 unit 文件可以已经安装在系统目录里，但尚未被当前 systemd manager 加载。此时直接查询它，可能得到空结果、找不到 unit，或者只能看到当前已加载关系。先用状态和来源信息确认对象：

# 先看 manager 是否认识这个 unit，再看它来自哪个文件
systemctl status example.service --no-pager
systemctl cat example.service

status 主要回答当前状态，cat 用来查看主文件与 drop-in 来源。两者都不能替代依赖图，但能把“服务没启动”和“服务根本未被加载”区分开。不要因为 unit 文件存在，就直接推断 list-dependencies 一定会列出它。

正向依赖与反向依赖要分开看

默认命令从目标 unit 出发，递归展示它需要或希望关联的 unit；官方手册列举的关系包括 Requires=、Requisite=、Wants=、ConsistsOf=、BindsTo= 和 Upholds=。想回答“哪些 unit 依赖我”，必须换成反向视角：

# 正向：目标服务依赖了谁
systemctl list-dependencies example.service

# 反向：哪些已加载单元把目标服务列为依赖
systemctl list-dependencies --reverse example.service

这两个结果的箭头方向相反，不能只看树的缩进就下结论。尤其是 --reverse 的结果仍受加载范围限制：未加载的消费者不会因为 unit 文件在磁盘上就自动出现在树里。

启动顺序不是依赖关系

有些故障看起来像“依赖没生效”，实际是把启动顺序和拉起关系混成了一件事。After=、Before= 只约束启动或停止时的先后；它们本身不会让另一个 unit 被启动，也不表示失败时一定联动。可以把顺序单独列出来：

# 只看目标 unit 的启动顺序关系
systemctl list-dependencies --after example.service
systemctl list-dependencies --before example.service

排障时建议形成“三栏记录”：正向依赖回答“它需要谁”，反向依赖回答“谁需要它”，顺序关系回答“谁先启动”。三栏都要注明查询时的加载状态，避免把一张局部视图误写成完整拓扑。

结果缺失时的四步排查清单

1. 确认 unit 名称是否带正确后缀，先用 systemctl status 看 manager 的认识结果。
2. 用 systemctl cat 确认主文件和 drop-in，避免只看了发行版默认文件。
3. 分别保存默认、--reverse、--after 和 --before 的输出，不混用箭头方向。
4. 如果要追磁盘上的潜在关系，再回到 unit 文件和 drop-in 做静态检查，不把当前命令输出冒充全量依赖数据库。

相关问题

为什么 unit 文件存在，list-dependencies 还是没有结果？

文件存在不等于当前 service manager 已加载它。先确认 unit 名称和 manager 视图，再结合主文件与 drop-in 做静态检查。

--reverse 能列出所有依赖当前服务的 unit 吗？

不能把它当作磁盘上的全量反向索引。它只能在当前已加载单元范围内展示反向关系。

After= 能代替 Requires= 吗？

不能。After= 和 Before= 只安排顺序；需要表达拉起、绑定或失败联动时，应检查对应的依赖关系配置。