Linux systemctl 怎样查看服务的反向依赖

排查 systemd 服务时，常见的现场不是“这个服务依赖谁”，而是“为什么这个服务会被拉起，哪些 unit 依赖它”。这时可以从目标 unit 反向查询：

# 反查当前系统管理器中依赖 nginx.service 的 unit
systemctl list-dependencies --reverse nginx.service

这里的 --reverse 改变的是依赖关系的观察方向：结果重点是哪些 unit 的需求关系指向 nginx.service。官方入口是 https://www.freedesktop.org/software/systemd/man/latest/systemctl.html，可复制到浏览器中查阅当前 systemctl 手册。需要注意，默认结果只覆盖 systemd 当前已经加载到内存的 unit，不能直接当作磁盘上全部依赖声明的完整清单。

最小用法是 systemctl list-dependencies --reverse 目标服务.service；结果为空不等于“没有任何反向依赖”，还要结合 --all、运行范围和 unit 文件继续判断。

一、先区分“它依赖谁”和“谁依赖它”

不加 --reverse 时，list-dependencies 通常从目标 unit 向外列出它要求或希望拉起的 unit。例如：

# 查看 nginx.service 自己声明或展开出的依赖
systemctl list-dependencies nginx.service

# 从相反方向查看哪些已加载 unit 需要 nginx.service
systemctl list-dependencies --reverse nginx.service

两条命令的目标相同，问题方向不同。前者适合解释“启动 nginx 需要哪些基础服务”；后者适合解释“哪个 target 或 service 把 nginx 纳入了自己的依赖网络”。systemctl 文档将 Requires=、Requisite=、Wants=、ConsistsOf=、BindsTo= 和 Upholds= 列为这类依赖关系，实际输出仍要结合 unit 类型和当前加载状态阅读。

二、用 --reverse 反查一个服务被谁拉起

假设问题是“某个后台服务总是随系统目标出现”，可以先把服务名写成完整 unit 名称，再看反向关系：

# 指定完整 unit 名称，减少同名模式带来的歧义
systemctl list-dependencies --reverse ssh.service

# 展开更多非 target 节点，便于继续追踪中间 unit
systemctl list-dependencies --reverse --all ssh.service

输出中的树形层级表示依赖网络中的嵌套关系，不应直接理解成“每一行都会按这个顺序执行”。如果只需要机器处理的结果，可以再考虑适合脚本的属性查询；但 list-dependencies 本身更偏向给人阅读的关系概览，排障时应保留目标 unit、查询范围和时间点。

三、为什么加了 --all 结果会变多

systemctl 默认会递归展开 target unit，而其它类型的 unit 可能只作为节点出现。--all 会要求继续展开更多 unit，因此在服务被多个中间 target 或辅助 service 间接引用时，结果通常更完整：

# 默认先看概要，适合快速判断是否存在反向引用
systemctl list-dependencies --reverse app-worker.service

# 需要追踪中间节点时展开全部可展开的 unit
systemctl list-dependencies --reverse --all app-worker.service

这里的“更完整”只针对当前 manager 已经加载的对象。官方说明明确提醒：该命令不适合获取某个 unit 的全部反向依赖，因为尚未加载的 unit 所声明的依赖不会出现在结果里。所以排查时不要把“没有输出”当成绝对结论，尤其是在服务尚未启动、目标 unit 只存在于磁盘文件或查询范围不对的情况下。

四、系统服务和用户服务要用不同的 manager

systemd 有系统级 manager，也有用户级 manager。若目标是用户服务，应该加 --user，否则可能在系统级范围里查不到它：

# 在系统级 manager 中反查系统服务
systemctl list-dependencies --reverse --all backup.service

# 在当前用户的 user manager 中反查用户服务
systemctl --user list-dependencies --reverse --all sync-agent.service

这两条命令查询的是不同的 unit 世界。--user 不是“把系统查询结果过滤成当前用户”，而是切换到用户态 manager；目标服务的安装位置、会话状态和启动方式也随之不同。遇到“服务文件明明存在但列表为空”，先确认它属于哪一个 manager，再检查 unit 是否已经被加载。

五、反向依赖不等于启动顺序

这是最容易混淆的一点。--reverse 主要回答“哪些 unit 在需求关系上指向目标 unit”；而 After= 和 Before= 约束的是启动、停止或其它 job 的排序。一个 unit 可以有顺序关系，却没有 Requires= 或 Wants= 这样的需求关系。

# 查看谁在需求关系上依赖目标服务
systemctl list-dependencies --reverse cache.service

# 观察与目标服务相关的 After/Before 排序关系
systemctl list-dependencies --reverse --after cache.service
systemctl list-dependencies --reverse --before cache.service

把这几条命令放在同一次排障中，可以回答两类不同问题：第一类是“谁会把它纳入依赖网络”，第二类是“谁和它存在先后顺序”。不要看到某个 unit 出现在 --after 结果里，就推断它一定会负责启动目标服务。

六、用 unit 文件和 show 命令回到可核对的证据

反向列表适合发现线索，确认具体声明时可以查看 unit 的来源文件与规范化属性：

# 查看 unit 文件、drop-in 和 systemd 当前可见的配置来源
systemctl cat app-worker.service

# 输出可供脚本处理的规范化属性，避免把 status 的人类摘要当成结构化接口
systemctl show app-worker.service --property=Requires,Wants,After,Before,BindsTo

systemctl cat 能帮助你定位 fragment 和 drop-in；systemctl show 更适合读取属性值。两者结合使用时，先用反向列表发现“可能是谁”，再回到对方 unit 文件检查是否真的写了对应的依赖或顺序声明。若文件刚刚修改，记得区分磁盘文件内容与 systemd manager 当前已加载的配置状态，必要时安排合适的 reload，再重新查询。

七、排障时可以按这张表选择命令

常见问题

为什么加了 --reverse 还是没有结果？

先确认目标 unit 名称、查询的是系统还是用户 manager，再用 --all 展开。仍为空时，检查声明依赖的 unit 是否已经被当前 manager 加载；官方文档明确说明，未加载 unit 的反向声明不会被这条命令完整列出。

--reverse 能不能查出所有依赖它的服务？

不能把它当作磁盘级全量索引。它适合查看当前 manager 已加载的依赖网络；需要做完整静态盘点时，还要读取 unit 文件和 drop-in，并明确系统级与用户级范围。

看启动先后应该用 --after 还是 --before？

根据你要观察的方向选择，并把它与 --reverse 分开理解。它们改变的是 ordering relationship 的观察方式，不会自动把顺序关系变成 Requires= 或 Wants=。

总结

systemctl list-dependencies --reverse 目标.service 是从服务出发查“谁依赖它”的最短路径。真实排障时再按顺序补上 --all、--user 和 --after/--before，最后用 systemctl cat、systemctl show 回到具体配置证据。记住它受当前 manager 加载范围限制，就不会把一个空结果误判成系统中不存在反向依赖。