答案：通过systemctl、包管理器和ldd命令可分别查看Linux服务、软件包和运行时库的依赖关系。首先使用systemctl status和list-dependencies分析服务依赖，再用apt或dnf查询软件包依赖，最后通过ldd检查可执行文件的动态库依赖，结合journalctl排查启动失败问题，合理利用工具可有效管理和解决依赖冲突。
在Linux系统里，想搞清楚一个程序或服务到底依赖了什么，这事儿说起来简单，做起来却常常让人挠头。不过别担心，核心思路其实就是分层来看：对于系统服务，
systemctl
是你的首选工具；而涉及到软件包层面，包管理器（比如
apt
或
dnf
）会给出答案；至于程序运行时的动态库，
ldd
命令则能帮你拨开迷雾。理解这些，能让你在系统维护和故障排查时少走很多弯路。
解决方案
要查看Linux中的依赖关系，特别是针对
systemd
服务和常规软件包，我们需要用到不同的工具和策略。
systemd服务依赖查看
systemd
是现代Linux发行版的核心，它的服务管理方式非常强大，同时也引入了复杂的依赖关系。
快速概览：
systemctl status
当你对某个服务感到好奇时，
systemctl status
是你的第一站。它不仅会告诉你服务当前的状态，还会列出其关键的依赖关系，比如
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
会给你一个惊喜。它会以树状结构展示一个服务所依赖的所有单元（包括服务、挂载点、目标等）。这对于理解一个服务的完整启动链条非常有用。
systemctl list-dependencies sshd.service
你还可以加上一些参数来调整显示：
--all
: 显示所有依赖，包括那些不活跃的。
--reverse
: 反向查看，哪些服务依赖于当前服务。
--before
/
--after
: 只看在当前服务之前或之后启动的依赖。
例如，查看
multi-user.target
这个常用目标单元的依赖，能让你对系统启动流程有个大致的认识：
systemctl list-dependencies multi-user.target
直接查看单元文件：
systemctl cat
深入了解一个服务的依赖，最直接的方法就是查看它的单元文件。
systemctl cat
会把该服务的
.service
文件内容打印出来。在
[Unit]
部分，你会找到
Requires=
,
Wants=
,
BindsTo=
,
Conflicts=
,
Before=
,
After=
等指令，它们定义了该服务与其他单元的交互方式。
systemctl cat apache2.service
软件包依赖查看
对于Linux上的软件包，不同发行版有不同的包管理器，但核心思想都是通过它们来查询。
Debian/Ubuntu (apt/dpkg):
查看一个包依赖了哪些包：
apt-cache depends
这会列出该软件包的所有直接依赖。
apt-cache depends apache2
查看哪些包依赖了当前包（反向依赖）：
apt-cache rdepends
这对于清理不再需要的包或者理解某个库的重要性很有帮助。
apt-cache rdepends libssl-dev
查看已安装包的详细信息：
dpkg -s
在输出中，你会看到
Depends:
字段，它列出了该包的直接依赖。
dpkg -s python3
RHEL/CentOS/Fedora (yum/dnf/rpm):
查看一个包依赖了哪些包：
dnf deplist
(或
yum deplist
)这个命令会详细列出软件包的依赖项，包括它们的版本要求和提供者。
dnf deplist httpd
查看哪些包依赖了当前包（反向依赖）：
repoquery --whatrequires
(需要安装
dnf-plugins-core
或
yum-utils
)这是一个非常实用的工具，可以帮你找出系统上哪些软件包依赖于某个特定的库或组件。
repoquery --whatrequires glibc
查看已安装包的详细信息：
rpm -qR
rpm -qR
会列出指定RPM包的运行时依赖项。
rpm -qR kernel
运行时库依赖查看
如果你想知道一个可执行文件在运行时需要哪些共享库，
ldd
命令是你的好朋友。
ldd /usr/bin/ls
它会列出所有动态链接库及其在系统中的路径。如果某个库显示
not found
，那么这个程序很可能无法正常运行。
理解systemd服务单元中的依赖类型及其作用
说实话，
systemd
的依赖关系是个既强大又有点让人摸不着头脑的东西。它远不止“这个服务需要那个服务”那么简单，而是通过一系列指令构建起一个复杂的启动和停止顺序网。理解这些指令，是掌握
systemd
的关键。
依图语音开放平台
依图语音开放平台
6 查看详情 
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
依然是起点，它会给你一个初步的错误提示。但要深入挖掘，你需要：
journalctl -xeu
这个命令会显示该服务的所有日志，并且
-x
会尝试解释一些错误，
-e
会跳到日志末尾，
u
过滤出特定服务的日志。
你可能会在日志中看到一些常见的依赖问题线索：
“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 aptitudesudo aptitude updatesudo aptitude install
清理旧内核或不再需要的包：有时候，旧的内核模块或其他不再使用的包会占用空间并可能引起依赖问题。
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
：如果你在安装或升级后发现系统出了问题，
dnf history
可以让你查看之前的操作记录，并通过
dnf history undo
回滚到之前的状态。这就像一个救命稻草，我用它救过好几次场。模块化（Modularity）：
dnf
在RHEL 8/Fedora 28+ 中引入了模块化概念，允许你安装同一软件的不同版本。比如，你可以选择安装
php:7.4
而不是
php:8.0
。
dnf module list phpdnf module enable php:7.4dnf install php
优先级和排除（Excludes）：在
/etc/yum.repos.d/
目录下，你可以为每个仓库设置优先级，或者在
dnf.conf
中使用
exclude
指令来排除某些包，从而避免冲突。
通用建议
避免盲目安装
.deb
或
.rpm
文件：这些包通常不包含所有依赖，或者其依赖版本与你的系统不兼容。如果非要安装，请务必使用
dpkg -i
或
rpm -i
后，再尝试用包管理器解决缺失依赖（
apt --fix-broken install
或
dnf install
）。容器化（Docker/Podman）：如果你的应用程序对依赖环境有非常严格或特殊的要求，或者与其他应用存在不可调和的依赖冲突，那么将应用容器化是终极解决方案。它能将应用及其所有依赖打包在一个隔离的环境中运行，完全避免了宿主机层面的依赖冲突。虽然引入了新的复杂性，但对于解决依赖地狱来说，这往往是最彻底且优雅的办法。
处理依赖冲突，有时候就像在玩一场高难度的拼图游戏。关键在于耐心，以及对系统和包管理器的基本理解。不要害怕尝试，但一定要记得备份或使用快照，以防万一。
以上就是如何在Linux中查看依赖 Linux systemctl依赖关系的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/429347.html
微信扫一扫 
支付宝扫一扫 
