要查看Linux中systemd单元的依赖关系，使用systemctl list-dependencies命令，可显示某单元的Wants、Requires等依赖类型，结合--reverse、--all、--type等参数能全面分析启动依赖与顺序，帮助排查服务故障。
在Linux中，如果你想查看一个
systemd单元（比如一个服务、一个挂载点或一个目标）所依赖的其他单元，最直接且官方推荐的方式就是使用
systemctl list-dependencies命令。这个命令能直观地展示出某个单元在启动或运行过程中需要哪些其他单元的支持，以及它又被哪些单元所依赖，这对于理解系统启动顺序、排查服务故障或者优化系统配置都非常有帮助。
解决方案
要查看Linux中
systemd单元的依赖关系，核心命令就是
systemctl list-dependencies。这个命令的用法其实很直接，你只需要在后面跟上你想查询的单元名称就行了。
例如，如果你想看看
nginx.service这个服务启动时都需要哪些东西：
systemctl list-dependencies nginx.service
执行后，你会看到一个树状结构，清晰地列出
nginx.service直接或间接
Wants（希望启动）或
Requires（必须启动）的单元。这里面会包含一些
target单元，比如
network.target，表明Nginx服务需要网络就绪才能正常工作。
有时，我们不仅想看一个服务依赖了什么，还想知道它被什么所依赖，或者它会在什么之后启动。
systemctl list-dependencies提供了一些参数来帮助我们更全面地分析。
-
查看反向依赖（即哪些单元依赖于它）：
systemctl list-dependencies --reverse nginx.service
这会显示哪些单元在启动时
Wants
或Requires
nginx.service
。 -
查看所有依赖（包括
After
和Before
）： 默认情况下，list-dependencies
主要显示Wants
和Requires
。如果你想看到更细致的启动顺序依赖，比如After
（在此之后启动）和Before
（在此之前启动），可以加上--all
参数：systemctl list-dependencies --all nginx.service
这个输出会更详细，但也会更复杂一些，因为它包含了更多关于启动顺序的信息。
-
只显示特定类型的依赖： 你可以指定只看
Requires
的：systemctl list-dependencies --type=service nginx.service
或者只看
target
的：systemctl list-dependencies --type=target nginx.service
理解这些依赖关系对于系统管理员来说，就像是外科医生了解人体解剖结构一样重要。它能让你在修改服务配置、升级系统组件时，预判可能带来的连锁反应。
深入剖析：systemctl list-dependencies
输出中的依赖类型解读
当我们运行
systemctl list-dependencies时，输出中那些带着不同前缀的行，比如
├─、
●、
○，以及单元名称后面的
Wants、
Requires等字样，其实蕴含着
systemd管理服务启动和停止的深层逻辑。对我来说，搞清楚这些不同类型的依赖，是真正掌握
systemd的关键。
systemd单元文件（通常在
/etc/systemd/system/或
/usr/lib/systemd/system/目录下）中的各种依赖指令，决定了
systemctl list-dependencies的输出。主要的依赖类型包括：
Requires=
： 这是最强的依赖关系。如果Requires
中列出的单元未能成功启动，那么当前单元也不会启动。反之，如果Requires
的单元在运行中途失败，当前单元也会被停止。这是一种“硬依赖”，通常用于那些没有它就无法正常工作的核心组件。例如，一个数据库服务可能Requires
其数据存储挂载点。 在list-dependencies
输出中，通常会以●
（实心圆点）或者直接显示为树状结构的一部分来表示，表示这是一个必须启动的依赖。Wants=
： 这是一种“弱依赖”。Wants
中列出的单元会被尝试启动，但如果它们启动失败，当前单元依然会尝试启动。这非常适合那些可选的、但存在会更好的服务。比如，一个Web服务器可能Wants
一个日志分析工具，即使日志工具没起来，Web服务本身也能跑。 在list-dependencies
输出中，Wants
通常会用○
（空心圆点）或者在单元名称后面明确标注Wants
来表示。After=
： 这个指令不表示依赖关系，而是定义了启动顺序。它确保当前单元在After
中列出的单元之后才启动。这意味着即使After
的单元启动失败，当前单元也可能尝试启动，但它会等到After
的单元尝试启动完毕（无论成功与否）后再行动。这对于避免竞态条件非常重要。比如，一个应用服务应该在数据库服务After
启动。Before=
： 与After
相反，Before
确保当前单元在Before
中列出的单元之前启动。这同样是关于启动顺序的，不强制依赖。Conflicts=
： 这个指令表示冲突。如果Conflicts
中列出的单元正在运行，那么当前单元将无法启动，反之亦然。这通常用于互斥的服务，比如两个不同的DHCP服务器。PartOf=
： 这是一个特殊的依赖，表示当前单元是另一个单元的一部分。当主单元停止时，PartOf
的单元也会停止。
理解这些，能帮助我们更好地分析
list-dependencies的输出。比如，如果一个服务启动失败，而它的
Requires列表里有某个单元也处于
failed状态，那基本就能确定问题根源了。而如果只是
Wants的单元失败，那么可能只是功能不完整，而不是服务本身无法启动。这细微的差别，在实际排查问题时非常关键。
解锁高级功能：systemctl list-dependencies
的实战技巧与参数详解
systemctl list-dependencies不仅仅是查看依赖那么简单，它的一些高级参数能让我们在特定场景下事半功倍。我个人在调试一些复杂的系统行为时，就经常用到这些“小技巧”，它们能帮我快速切入问题的核心。
-
递归深度控制：
--plain
和--recursive
默认情况下，list-dependencies
会以树状结构展示递归依赖。但有时，树太深了，看得眼花缭乱。 如果你只想看直接依赖，不希望看到深层嵌套，可以使用--plain
参数，它会把所有依赖扁平化输出，并且不显示层级关系。虽然失去了直观的树状结构，但在某些自动化脚本或需要快速提取所有依赖列表的场景下，它很有用。systemctl list-dependencies --plain nginx.service
反过来，如果你想确保看到所有可能的深层依赖，尽管默认就是递归的，但明确使用
--recursive
可以强调这一点，特别是当你想确认某个深层组件是否被某个服务间接依赖时。 -
过滤特定状态的单元：
--state=
这个参数非常实用。我们不光想知道有哪些依赖，更想知道这些依赖现在处于什么状态。比如，我只想看看那些“激活中”的依赖，或者“失败”的依赖：systemctl list-dependencies --state=active nginx.service systemctl list-dependencies --state=failed nginx.service
这在排查问题时特别有用，可以迅速聚焦到那些可能导致当前服务问题的依赖单元上。
-
结合
grep
进行筛选： 虽然systemctl list-dependencies
本身有过滤功能，但结合grep
这种通用的文本处理工具，能实现更灵活的筛选。比如，我只想看nginx.service
的所有依赖中，包含network
字样的：systemctl list-dependencies nginx.service | grep network
这对于在大量依赖中寻找特定类型的资源（如网络、存储、用户）非常高效。
-
查看系统默认目标的依赖：
systemd
通过target
单元来管理系统的不同运行级别。例如，multi-user.target
代表多用户命令行模式，graphical.target
代表图形界面模式。查看它们的依赖，可以帮助我们理解系统启动时到底会启动哪些服务：systemctl list-dependencies multi-user.target
这能让你对系统启动流程有一个全局的认识，比如哪些服务是开机必启动的。
-
用户会话服务的依赖：
--user
除了系统服务，systemd
也管理用户会话服务。如果你想查看某个用户会话服务的依赖，比如你的桌面环境组件，就需要加上--user
参数：systemctl list-dependencies --user pulseaudio.service
这对于调试桌面环境中的音频、网络代理等用户级服务很有帮助。
这些高级用法让
systemctl list-dependencies从一个简单的查询工具，变成了一个强大的诊断和分析平台。掌握它们，无疑能大大提升我们处理
systemd相关问题的效率。
服务启动故障排查利器：如何利用 systemctl list-dependencies
快速定位问题
服务启动失败，这是每个系统管理员都会遇到的“家常便饭”。当
systemctl status some-service告诉你服务启动失败，日志里又没有明确的错误信息时，我通常会把目光投向
systemctl list-dependencies。这个命令简直就是排查这类问题的“侦探”工具，它能帮我们迅速锁定问题可能出在哪里。
1. 检查缺失的硬依赖（Requires=
）：
如果一个服务启动失败，首先要怀疑的是它的硬依赖（
Requires=）是否没有成功启动。 运行：
systemctl list-dependencies your-failed-service.service
仔细查看输出，特别是那些
●（实心圆点）表示的
Requires依赖。如果其中有任何一个单元处于
failed或
inactive状态，那么很可能就是导致你的服务无法启动的直接原因。 例如，如果
your-failed-service.service
Requires
database.service，而
database.service处于
failed状态，那么问题就出在数据库服务上。这时，你需要先去排查
database.service的问题。
2. 识别潜在的弱依赖问题（Wants=
）：
虽然
Wants的单元启动失败不会阻止当前服务启动，但在某些情况下，如果被
Wants的单元提供了关键功能，它的缺失仍然可能导致服务表现异常。 通过
list-dependencies查看
Wants的单元，结合
systemctl status去检查这些单元的状态，可以帮助我们理解服务为何功能不全或行为异常。
3. 分析启动顺序（After=
/ Before=
）：
有时，服务本身没问题，但它启动得太早或太晚，导致依赖资源还没准备好。
使用
systemctl list-dependencies --all your-failed-service.service可以显示
After和
Before关系。 如果你发现你的服务在某个它
After的单元之前就尝试启动了（这通常意味着单元文件配置错误或者存在循环依赖），那就会出问题。检查单元文件中的
After=指令是否正确指向了所有必要的先行服务。 我曾经遇到过一个Web应用服务，它
After=network.target，但却没有
After=mariadb.service，结果导致在某些启动时序不确定的情况下，Web应用在数据库还没完全启动就尝试连接，从而失败。
list-dependencies帮我快速定位了这个问题，只需在Web应用的服务文件中加上
After=mariadb.service就解决了。
4. 发现循环依赖： 虽然
systemd设计上会尽量避免循环依赖，但在手动创建或修改单元文件时，不小心引入循环依赖是可能的。
systemctl list-dependencies的树状输出在某些情况下可以帮助你发现这种循环，即一个服务A依赖B，B又依赖A，或者更复杂的链条。如果输出的树状结构看起来很奇怪，或者某个单元反复出现，就值得怀疑了。虽然
systemd通常会报错并尝试打破循环，但提前发现总归是好的。
5. 结合journalctl
进行深度分析：
一旦通过
list-dependencies锁定了可能的依赖单元，下一步就是使用
journalctl -u problematic-dependency.service来查看该依赖单元的详细日志。
list-dependencies提供了方向，
journalctl提供了细节，两者结合，故障排查的效率会大大提高。
通过这种系统性的方法，将
systemctl list-dependencies作为故障排查的第一步，可以帮助我们避免盲目猜测，更快速、更精准地定位服务启动失败的真正原因。
