如何查看服务依赖关系 systemd依赖树分析-linux运维-PHP中文网

要查看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=确保启动时序。排查故障时，首先检查依赖服务状态，通过依赖树定位直接或间接问题根源，识别启动顺序错误，并利用反向依赖评估服务停止的影响范围，从而高效诊断和解决服务启动失败或运行异常问题。

如何查看服务依赖关系 systemd依赖树分析

在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对服务间关系的精确定义。理解这些符号和关键词，是掌握依赖分析的关键。

输出通常会以层级结构展示，每个缩进代表一层依赖。

依图语音开放平台

查看详情

●
登录后复制
(实心圆)：表示该服务当前处于“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 Server
Documentation=https://example.com/docs
Requires=mysql.service  # 强制依赖MySQL，MySQL不起来我也不起来
Wants=network-online.target # 希望网络在线，但不强制，即使网络有点问题我也尝试启动
After=mysql.service network-online.target # 确保在MySQL和网络之后启动

[Service]
User=webuser
Group=webgroup
WorkingDirectory=/opt/mywebserver
ExecStart=/usr/bin/python3 /opt/mywebserver/app.py
Restart=on-failure
StandardOutput=journal
StandardError=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]
```
登录后复制
可以让你看到哪些其他服务会因此受到影响。这在规划维护窗口和评估风险时非常宝贵，可以避免不必要的级联故障。