如何在Linux中查看依赖 Linux systemctl依赖关系-linux运维-PHP中文网

答案：通过systemctl、包管理器和ldd命令可分别查看Linux服务、软件包和运行时库的依赖关系。首先使用systemctl status和list-dependencies分析服务依赖，再用apt或dnf查询软件包依赖，最后通过ldd检查可执行文件的动态库依赖，结合journalctl排查启动失败问题，合理利用工具可有效管理和解决依赖冲突。

如何在linux中查看依赖 linux systemctl依赖关系

在Linux系统里，想搞清楚一个程序或服务到底依赖了什么，这事儿说起来简单，做起来却常常让人挠头。不过别担心，核心思路其实就是分层来看：对于系统服务，

systemctl

登录后复制

是你的首选工具；而涉及到软件包层面，包管理器（比如

apt

登录后复制

或

dnf

登录后复制

）会给出答案；至于程序运行时的动态库，

ldd

登录后复制

命令则能帮你拨开迷雾。理解这些，能让你在系统维护和故障排查时少走很多弯路。

解决方案

要查看Linux中的依赖关系，特别是针对

systemd

登录后复制

服务和常规软件包，我们需要用到不同的工具和策略。

systemd服务依赖查看

systemd

登录后复制

是现代Linux发行版的核心，它的服务管理方式非常强大，同时也引入了复杂的依赖关系。

快速概览：
```
systemctl status
```
登录后复制
当你对某个服务感到好奇时，
```
systemctl status <service_name>
```
登录后复制
是你的第一站。它不仅会告诉你服务当前的状态，还会列出其关键的依赖关系，比如
```
Requires
```
登录后复制
(强依赖，依赖服务必须启动)，
```
Wants
```
登录后复制
(弱依赖，依赖服务最好启动但非必须)，以及
```
Before
```
登录后复制
和
```
After
```
登录后复制
(控制启动顺序)。这就像是服务的“健康报告”，附带了它最亲密的伙伴信息。
```
systemctl status sshd.service
```
登录后复制
输出中你会看到类似这样的行：
```
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
```
登录后复制
```
Active: active (running) since ...
```
登录后复制
```
Docs: man:sshd(8)
```
登录后复制
```
man:sshd_config(5)
```
登录后复制
```
Requires: sshdgenkeys.service
```
登录后复制
```
After: network.target sshdgenkeys.service auditd.service
```
登录后复制
```
Before: systemd-user-sessions.service
```
登录后复制
树状结构：
```
systemctl list-dependencies
```
登录后复制
如果你想看到更全面的依赖图，
```
systemctl list-dependencies <service_name>
```
登录后复制
会给你一个惊喜。它会以树状结构展示一个服务所依赖的所有单元（包括服务、挂载点、目标等）。这对于理解一个服务的完整启动链条非常有用。
```
systemctl list-dependencies sshd.service
```
登录后复制
你还可以加上一些参数来调整显示：
- ```
--all
```
  登录后复制
  : 显示所有依赖，包括那些不活跃的。
- ```
--reverse
```
  登录后复制
  : 反向查看，哪些服务依赖于当前服务。
- ```
--before
```
  登录后复制
  /
```
--after
```
  登录后复制
  : 只看在当前服务之前或之后启动的依赖。
例如，查看
```
multi-user.target
```
登录后复制
这个常用目标单元的依赖，能让你对系统启动流程有个大致的认识：
```
systemctl list-dependencies multi-user.target
```
登录后复制
直接查看单元文件：
```
systemctl cat
```
登录后复制
深入了解一个服务的依赖，最直接的方法就是查看它的单元文件。
```
systemctl cat <service_name>
```
登录后复制
会把该服务的
```
.service
```
登录后复制
文件内容打印出来。在
```
[Unit]
```
登录后复制
部分，你会找到
```
Requires=
```
登录后复制
,
```
Wants=
```
登录后复制
,
```
BindsTo=
```
登录后复制
,
```
Conflicts=
```
登录后复制
,
```
Before=
```
登录后复制
,
```
After=
```
登录后复制
等指令，它们定义了该服务与其他单元的交互方式。
```
systemctl cat apache2.service
```
登录后复制

软件包依赖查看

对于Linux上的软件包，不同发行版有不同的包管理器，但核心思想都是通过它们来查询。

Debian/Ubuntu (apt/dpkg):
- 查看一个包依赖了哪些包：
  apt-cache depends <package_name>
  登录后复制
  这会列出该软件包的所有直接依赖。
```
apt-cache depends apache2
```
  登录后复制
- 查看哪些包依赖了当前包（反向依赖）：
  apt-cache rdepends <package_name>
  登录后复制
  这对于清理不再需要的包或者理解某个库的重要性很有帮助。
```
apt-cache rdepends libssl-dev
```
  登录后复制
- 查看已安装包的详细信息：
  dpkg -s <package_name>
  登录后复制
  在输出中，你会看到
```
Depends:
```
  登录后复制
  字段，它列出了该包的直接依赖。
```
dpkg -s python3
```
  登录后复制
RHEL/CentOS/Fedora (yum/dnf/rpm):
- 查看一个包依赖了哪些包：
  dnf deplist <package_name>
  登录后复制
  (或
  yum deplist <package_name>
  登录后复制
  ) 这个命令会详细列出软件包的依赖项，包括它们的版本要求和提供者。
```
dnf deplist httpd
```
  登录后复制
- 查看哪些包依赖了当前包（反向依赖）：
  repoquery --whatrequires <package_name>
  登录后复制
  (需要安装
  dnf-plugins-core
  登录后复制
  或
  yum-utils
  登录后复制
  ) 这是一个非常实用的工具，可以帮你找出系统上哪些软件包依赖于某个特定的库或组件。
```
repoquery --whatrequires glibc
```
  登录后复制
- 查看已安装包的详细信息：
  rpm -qR <package_name>
  登录后复制
```
rpm -qR
```
  登录后复制
  会列出指定RPM包的运行时依赖项。
```
rpm -qR kernel
```
  登录后复制

运行时库依赖查看

如果你想知道一个可执行文件在运行时需要哪些共享库，

ldd

登录后复制

命令是你的好朋友。

ldd /usr/bin/ls

登录后复制

它会列出所有动态链接库及其在系统中的路径。如果某个库显示

not found

登录后复制

，那么这个程序很可能无法正常运行。

理解systemd服务单元中的依赖类型及其作用

说实话，

systemd

登录后复制

的依赖关系是个既强大又有点让人摸不着头脑的东西。它远不止“这个服务需要那个服务”那么简单，而是通过一系列指令构建起一个复杂的启动和停止顺序网。理解这些指令，是掌握

systemd

登录后复制

的关键。

依图语音开放平台

查看详情

Requires=
登录后复制
(强依赖)：这是最严格的依赖。如果
```
Requires=
```
登录后复制
指明的服务没有启动成功，或者在当前服务启动前就失败了，那么当前服务也不会启动。你可以把它想象成“非你不可”的关系。举个例子，一个数据库应用服务可能
```
Requires=
```
登录后复制
数据库服务本身，如果数据库没起来，应用服务启动也没意义。
Wants=
登录后复制
(弱依赖)：相比
```
Requires=
```
登录后复制
，
```
Wants=
```
登录后复制
就温柔多了。它表示当前服务“希望”被依赖的服务能够启动，但即使被依赖的服务没有启动成功，当前服务也会尝试启动。这更像是一种“最好有你，没有也行”的关系。很多服务会
```
Wants=
```
登录后复制
像
```
network-online.target
```
登录后复制
这样的目标，意思是如果网络好了我能更好地工作，但就算网络没完全就绪，我也先尝试启动。
BindsTo=
登录后复制
(绑定依赖)：这个有点特殊，它不仅要求被依赖的服务启动成功，而且如果被依赖的服务停止或崩溃了，当前服务也会跟着停止。这通常用于那些生命周期紧密绑定的组件，比如一个主服务和它的某个辅助进程。
Conflicts=
登录后复制
(冲突)：顾名思义，这表示当前服务与某个其他服务是互斥的，不能同时运行。如果
```
Conflicts=
```
登录后复制
指明的服务正在运行，当前服务就不会启动，反之亦然。这在管理不同版本的软件或替代方案时很有用，比如
```
nginx
```
登录后复制
和
```
apache
```
登录后复制
可能在某些配置下会
```
Conflicts=
```
登录后复制
。
Before=
登录后复制
和
After=
登录后复制
(顺序依赖)：这两个指令不表示依赖关系本身，而是控制服务的启动和停止顺序。
```
Before=foo.service
```
登录后复制
意味着当前服务必须在
```
foo.service
```
登录后复制
启动之前启动。
```
After=bar.service
```
登录后复制
则意味着当前服务必须在
```
bar.service
```
登录后复制
启动之后启动。它们是确保系统组件按正确次序就绪的关键。比如，绝大多数网络服务都会
```
After=network.target
```
登录后复制
或
```
After=network-online.target
```
登录后复制
，确保网络环境准备好之后再启动。

在我看来，

Requires=

登录后复制

和

Wants=

登录后复制

的区别最容易让人混淆。我个人经验是，如果一个服务没有它依赖的服务就完全无法工作，那就用

Requires=

登录后复制

；如果只是功能受限但仍能提供部分服务，或者只是为了优化启动流程，那么

Wants=

登录后复制

更合适。而

Before=

登录后复制

和

After=

登录后复制

则是纯粹的编排艺术，它们决定了你的系统是井然有序地启动，还是乱成一锅粥。

诊断Linux服务启动失败的常见依赖问题

服务启动失败，这几乎是每个Linux管理员的噩梦。很多时候，罪魁祸首就是依赖问题。当你面对一个红色的

failed

登录后复制

状态时，不要慌，

journalctl

登录后复制

是你最好的侦探。

首先，

systemctl status <failed_service>

登录后复制

依然是起点，它会给你一个初步的错误提示。但要深入挖掘，你需要：

journalctl -xeu <failed_service>

登录后复制

这个命令会显示该服务的所有日志，并且

-x

登录后复制

会尝试解释一些错误，

-e

登录后复制

会跳到日志末尾，

登录后复制

过滤出特定服务的日志。

你可能会在日志中看到一些常见的依赖问题线索：

"Failed to start "：这通常是最直接的提示，明确告诉你某个依赖服务未能启动。这时，你需要暂停对当前服务的排查，转而调查那个依赖服务为什么失败。可能是它的配置问题，也可能是它自身还有更深层的依赖问题。
"Unit not found"：这表明服务尝试依赖一个不存在的单元。可能是单元文件名写错了，或者对应的软件包根本没安装。我遇到过几次，就是因为手滑多打了一个字母，或者在不同发行版之间迁移配置时，单元名有所差异。
"Timeout waiting for "：服务在等待某个目标（比如
```
network-online.target
```
登录后复制
）就绪时超时。这通常意味着网络配置有问题，或者依赖的目标本身就没能按时达成。这种情况在虚拟机或容器环境中比较常见，因为网络初始化可能比预期慢。
"Dependency failed for "：这是一个概括性的错误，表示当前服务因为某个依赖失败而无法启动。你需要向上翻日志，寻找更具体的失败原因。

有时候，问题并不在于依赖服务没有启动，而在于依赖服务虽然启动了，但没有达到当前服务所期望的“就绪”状态。比如，一个数据库服务可能已经

active (running)

登录后复制

，但它的端口还没开始监听，或者内部初始化还没完成，导致依赖它的应用服务连接失败。这种情况下，你需要检查依赖服务自身的日志，或者使用

ExecStartPre=

登录后复制

和

ExecStartPost=

登录后复制

等指令，在单元文件中加入健康检查，确保依赖服务真正可用。

还有一种“鸡生蛋，蛋生鸡”的问题，就是两个服务相互

Requires=

登录后复制

或

After=

登录后复制

对方，形成死锁。

systemd

登录后复制

通常能检测到这种循环依赖并报错，但如果配置复杂，也可能导致一些服务无法启动。这时，仔细审查

systemctl cat

登录后复制

出来的单元文件，理清

Before=

登录后复制

和

After=

登录后复制

的逻辑，是解决问题的关键。

如何有效地管理和解决Linux软件包的依赖冲突

软件包依赖冲突，这是Linux用户经常会遇到的一个痛点。当你试图安装一个新软件，或者升级现有系统时，包管理器突然报错，说某个库的版本不兼容，或者某个包与其他已安装的包冲突，那种感觉简直让人抓狂。

解决这些问题，首先要理解冲突的来源：

版本不兼容：最常见的情况，新软件需要
```
libfoo.so.2.0
```
登录后复制
，而系统上只有
```
libfoo.so.1.0
```
登录后复制
，或者反过来。
文件冲突：两个不同的软件包尝试安装同一个文件到相同路径。
仓库冲突：启用了多个提供相同软件包但版本不同的软件源，导致包管理器不知道该选哪个。

针对Debian/Ubuntu (apt)

apt install --no-install-recommends
登录后复制
：默认情况下，
```
apt
```
登录后复制
会安装推荐（Recommends）和建议（Suggests）的包。虽然这些通常是好的，但有时候也会引入不必要的依赖或冲突。使用这个选项可以只安装强依赖的包。
aptitude
登录后复制
：对于更复杂的依赖冲突，
```
aptitude
```
登录后复制
是一个强大的交互式工具。它通常能提供多种解决方案，让你选择最合适的。我个人在处理一些老旧系统或复杂升级时，经常会求助于它。
```
sudo apt install aptitude
sudo aptitude update
sudo aptitude install <package_name>
```
登录后复制
清理旧内核或不再需要的包：有时候，旧的内核模块或其他不再使用的包会占用空间并可能引起依赖问题。
```
sudo apt autoremove
```
登录后复制
是一个好习惯。
管理软件源：确保你的
```
/etc/apt/sources.list
```
登录后复制
和
```
/etc/apt/sources.list.d/
```
登录后复制
目录下的文件配置正确，避免启用相互冲突的第三方仓库。优先使用官方仓库，除非你明确知道自己在做什么。

针对RHEL/CentOS/Fedora (dnf)

dnf install --setopt=install_weak_deps=False
登录后复制
：类似于
```
apt
```
登录后复制
的
```
--no-install-recommends
```
登录后复制
，
```
dnf
```
登录后复制
也有弱依赖的概念。这个选项可以避免安装那些非必要的依赖。
dnf history undo <transaction_id>
登录后复制
：如果你在安装或升级后发现系统出了问题，
```
dnf history
```
登录后复制
可以让你查看之前的操作记录，并通过
```
dnf history undo
```
登录后复制
回滚到之前的状态。这就像一个救命稻草，我用它救过好几次场。
模块化（Modularity）：
```
dnf
```
登录后复制
在RHEL 8/Fedora 28+ 中引入了模块化概念，允许你安装同一软件的不同版本。比如，你可以选择安装
```
php:7.4
```
登录后复制
而不是
```
php:8.0
```
登录后复制
。
```
dnf module list php
dnf module enable php:7.4
dnf install php
```
登录后复制
优先级和排除（Excludes）：在
```
/etc/yum.repos.d/
```
登录后复制
目录下，你可以为每个仓库设置优先级，或者在
```
dnf.conf
```
登录后复制
中使用
```
exclude
```
登录后复制
指令来排除某些包，从而避免冲突。

通用建议

避免盲目安装
.deb
登录后复制
或
.rpm
登录后复制
文件：这些包通常不包含所有依赖，或者其依赖版本与你的系统不兼容。如果非要安装，请务必使用
```
dpkg -i
```
登录后复制
或
```
rpm -i
```
登录后复制
后，再尝试用包管理器解决缺失依赖（
```
apt --fix-broken install
```
登录后复制
或
```
dnf install
```
登录后复制
）。
容器化（Docker/Podman）：如果你的应用程序对依赖环境有非常严格或特殊的要求，或者与其他应用存在不可调和的依赖冲突，那么将应用容器化是终极解决方案。它能将应用及其所有依赖打包在一个隔离的环境中运行，完全避免了宿主机层面的依赖冲突。虽然引入了新的复杂性，但对于解决依赖地狱来说，这往往是最彻底且优雅的办法。