要查看linux系统中systemd服务的依赖关系，最直接的方法是使用systemctl list-dependencies命令。1. 使用systemctl list-dependencies sshd.service可查看sshd.service的正向依赖树；2. 添加–all选项可显示包括“wants”在内的所有依赖类型；3. 使用–reverse选项可查看哪些服务依赖sshd.service；4. 结合–before或–after可分析启动顺序。输出中●表示服务运行中，○表示未运行，->表示依赖关系，目标单元（.target）用于逻辑分组。在自定义服务时，应在[unit]段中使用requires=、wants=、after=等指令正确声明依赖，确保启动顺序和运行条件，如requires=mysql.service表示强依赖，wants=network-online.target表示弱依赖，after=确保启动时序。排查故障时，首先检查依赖服务状态，通过依赖树定位直接或间接问题根源，识别启动顺序错误，并利用反向依赖评估服务停止的影响范围，从而高效诊断和解决服务启动失败或运行异常问题。
在Linux系统上，尤其是使用systemd作为初始化系统时，要查看服务间的依赖关系，最直接且高效的方式是利用
systemctl
命令配合其强大的依赖分析功能。这能帮助我们快速理解一个服务为何启动、为何失败，或者它又支撑着哪些其他关键组件的运行。
解决方案
要深入了解一个systemd服务的依赖树，核心工具就是
systemctl list-dependencies
命令。这个命令能够递归地列出指定服务或目标单元所需要的所有依赖项。
例如，如果你想查看
sshd.service
（SSH守护进程）的依赖关系，你可以这样操作：
systemctl list-dependencies sshd.service
这个命令的输出会以树状结构展示
sshd.service
直接或间接依赖的其他服务和目标。
如果想看到更全面的依赖类型，包括那些并非强制性的“Wants”依赖，可以加上
--all
选项：
systemctl list-dependencies --all sshd.service
有时候，我们不仅想知道一个服务依赖什么，还想知道哪些服务依赖它。这在进行服务维护或停机时尤其重要，可以避免“牵一发而动全身”的意外。这时，
--reverse
选项就派上用场了：
systemctl list-dependencies --reverse sshd.service
它会列出所有将
sshd.service
作为其依赖的服务。
此外，你还可以结合
--before
或
--after
来查看特定排序的依赖关系，但这通常在分析具体启动顺序问题时更常用。
实际操作中，我发现
list-dependencies
给出的视图非常直观，特别是当你在排查某个服务启动失败，或者想优化启动流程时，它能迅速帮你定位到潜在的问题点。
如何解读
systemctl list-dependencies
的输出？
systemctl list-dependencies
的输出，初看可能只是一堆嵌套的服务名，但它背后蕴含着systemd对服务间关系的精确定义。理解这些符号和关键词，是掌握依赖分析的关键。
输出通常会以层级结构展示，每个缩进代表一层依赖。
依图语音开放平台
依图语音开放平台
6 查看详情
●
(实心圆)：表示该服务当前处于“active”状态，也就是正在运行。
○
(空心圆)：表示该服务处于“inactive”状态，即未运行或已停止。
->
(箭头)：指示一个“Requires”或“Wants”类型的依赖关系。箭头指向的服务是被依赖方。
更深层次的理解，需要知道systemd定义了几种主要的依赖类型，它们通常在服务的
.service
单元文件中被声明：
Requires=
：这是最强烈的依赖。如果被依赖的服务未能启动，那么依赖它的服务也无法启动。如果被依赖的服务在运行时停止，那么依赖它的服务也会被停止。这就像一个硬性要求，缺一不可。
Wants=
：这是一种“软”依赖。Systemd会尝试启动被
Wants
的服务，但如果它启动失败，依赖它的服务依然可以继续尝试启动。这在很多情况下很有用，比如一个服务“希望”某个日志收集器启动，但即使日志收集器没起来，核心服务也能继续工作。
After=
：定义了服务的启动顺序。它不强制被依赖服务必须启动，但要求如果两者都要启动，那么被依赖的服务必须在它之前启动。这对于确保数据库在应用服务器之前启动，或者网络服务在其他需要网络的进程之前启动至关重要。
Before=
：与
After=
相反，要求自身在被依赖服务之前启动。
Conflicts=
：表示两个服务不能同时运行。如果一个服务启动，那么与其冲突的服务会被停止。
在
list-dependencies
的输出中，你可能会看到很多以
.target
结尾的单元。这些是“目标单元”，它们本身不提供具体功能，而是作为一组服务的逻辑分组点。例如，
multi-user.target
代表了多用户命令行模式所需的所有服务。很多服务会
WantedBy=multi-user.target
，这意味着它们是多用户模式的一部分。理解这些目标，能帮助你把握系统启动的宏观流程。
我个人在排查问题时，会特别留意那些“inactive”的依赖服务，因为它们很可能是导致上层服务无法启动的直接原因。
在自定义服务时如何正确设置依赖？
当我们需要创建或修改自定义的systemd服务时，正确配置依赖关系是确保服务稳定运行的关键。一个服务单元文件（通常是
.service
文件）通常包含
[Unit]
、
[Service]
和
[Install]
三个主要部分，而依赖关系的定义主要集中在
[Unit]
部分。
在
[Unit]
部分，你可以使用前面提到的
Requires=
、
Wants=
、
After=
、
Before=
等指令来定义你的服务与其他服务或目标的关系。
这里是一个简单的例子，假设你有一个自定义的Python Web服务，它需要数据库（比如
mysql.service
）和网络（比如
network-online.target
）都准备好才能启动：
# /etc/systemd/system/mywebserver.service[Unit]Description=My Custom Python Web ServerDocumentation=https://example.com/docsRequires=mysql.service # 强制依赖MySQL，MySQL不起来我也不起来Wants=network-online.target # 希望网络在线，但不强制，即使网络有点问题我也尝试启动After=mysql.service network-online.target # 确保在MySQL和网络之后启动[Service]User=webuserGroup=webgroupWorkingDirectory=/opt/mywebserverExecStart=/usr/bin/python3 /opt/mywebserver/app.pyRestart=on-failureStandardOutput=journalStandardError=journal[Install]WantedBy=multi-user.target # 当系统进入多用户模式时，希望启动这个服务
在这个例子中：
Requires=mysql.service
：如果
mysql.service
没起来，
mywebserver.service
也不会尝试启动。
Wants=network-online.target
：systemd会尝试启动
network-online.target
，即使它失败了，
mywebserver.service
也会尝试启动。
network-online.target
通常表示网络接口已经配置好并能访问外部网络。
After=mysql.service network-online.target
：这确保了即使这两个服务都成功启动，
mywebserver.service
也总是在它们之后启动。这非常重要，因为你的Web应用需要数据库连接和网络功能才能正常工作。
配置完服务文件后，你需要运行
sudo systemctl daemon-reload
来让systemd重新加载配置，然后才能
sudo systemctl enable mywebserver.service
和
sudo systemctl start mywebserver.service
。
我遇到过不少情况，服务就是不启动或者启动后很快崩溃，最后发现都是因为没有正确设置
After=
导致它在依赖的服务还没准备好时就冲动启动了。所以，理解并正确使用这些依赖指令，能省去很多不必要的调试时间。
服务依赖分析在故障排除中的应用？
服务依赖分析在系统故障排除中扮演着至关重要的角色，它几乎是我每次遇到服务启动问题时的第一步。当一个服务行为异常，或者根本无法启动时，查看其依赖关系往往能迅速揭示问题的根源。
想象一下这个场景：你发现你的Web服务器（比如Nginx）无法启动。你习惯性地运行
systemctl status nginx.service
，输出显示它失败了，但错误信息可能不够明确，或者指向的是一个更深层的问题。这时，依赖分析就能派上用场了。
检查直接依赖是否正常：首先，我会用
systemctl list-dependencies nginx.service
查看Nginx依赖什么。假设它依赖
network.target
和
php-fpm.service
。然后，我会逐一检查这些依赖的状态：
systemctl status network.target
：网络是否正常？
systemctl status php-fpm.service
：PHP-FPM是否运行？
如果发现
php-fpm.service
是
inactive
的，那么问题就缩小到PHP-FPM本身了。接下来，我就会去排查PHP-FPM的问题，而不是在Nginx上耗费时间。这就像是顺着一条线索，一步步追溯到最初的源头。
识别间接依赖问题：有时候，问题不是直接依赖，而是依赖的依赖出了问题。
list-dependencies
的递归特性在这里就很有用。它可以帮助你看到整个链条，即使是深层的数据库连接问题，也能通过层层依赖追溯到。
处理启动顺序问题：如果服务能启动，但功能异常，可能是启动顺序出了问题。例如，你的应用服务在数据库服务完全初始化并监听端口之前就启动了，导致连接失败。通过分析
After=
和
Before=
关系，可以确认是否存在这样的时序问题，并据此调整服务配置。
理解服务影响范围：当一个核心服务需要停止或重启时，使用
systemctl list-dependencies --reverse [core_service]
可以让你看到哪些其他服务会因此受到影响。这在规划维护窗口和评估风险时非常宝贵，可以避免不必要的级联故障。
在我的经验中，很多看似复杂的系统问题，最终都归结为某个基础服务的依赖没有满足。systemd的依赖树分析工具，就像一个X光机，能帮助你快速透视系统内部，找出那些隐藏的关联和潜在的瓶颈。它不是解决所有问题的万能药，但绝对是诊断问题、提高效率的利器。
以上就是如何查看服务依赖关系 systemd依赖树分析的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/446132.html
微信扫一扫 
支付宝扫一扫 
