要查看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
中列出的单元之前启动。这同样是关于启动顺序的，不强制依赖。
PatentPal专利申请写作
AI软件来为专利申请自动生成内容
266 查看详情 
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.servicesystemctl 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
作为故障排查的第一步，可以帮助我们避免盲目猜测，更快速、更精准地定位服务启动失败的真正原因。
以上就是如何在Linux中查看依赖 Linux systemctl list-dependencies的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/806364.html
微信扫一扫 
支付宝扫一扫 
