故障排除 Systemd：理解服务依赖关系和排序指令
Systemd 是现代 Linux 上的系统和服务管理器，它提供了一种强大而灵活的方式来管理系统服务。配置 systemd 时一个常见的挑战是确保服务以正确的顺序启动并且其依赖项得到正确满足。配置错误的依赖项可能导致竞态条件，即某个服务在其先决条件准备就绪之前尝试启动，从而导致失败或意外行为。本文深入探讨了控制服务依赖关系和排序的关键 systemd 单元文件指令：Requires、Wants、After 和 Before。理解并正确实现这些指令对于构建健壮可靠的系统配置至关重要。
妥善管理服务依赖关系不仅仅是为了防止启动失败；更是为了创建一个可预测且稳定的运行环境。当服务相互依赖时，systemd 需要明确的指令来协调它们的启动和关闭。未能提供这些指令可能会表现出难以追踪的微妙错误，这些错误通常只在特定负载条件或系统重启期间出现。通过掌握依赖关系和排序指令，您可以对服务生命周期进行精细控制，并确保关键应用程序和系统组件按预期运行。
核心依赖指令：Requires 和 Wants
Systemd 使用两个主要的指令来定义单元之间的直接依赖关系：Requires 和 Wants。这些指令放置在单元文件（例如 .service 文件）的 [Unit] 部分中。
Requires=
Requires= 指令建立了一个强依赖关系。如果单元 A Requires= 单元 B，那么单元 B 必须处于激活状态，单元 A 才被认为成功激活。如果单元 B 激活失败或被停止，单元 A 也将被停止或阻止启动。这是一种关键关系，其中所需单元的失败会直接影响依赖的单元。
示例：
考虑一个严重依赖数据库服务（mariadb.service）的 Web 应用程序服务（myapp.service）。myapp.service 单元文件可能包含：
[Unit]
Description=我的 Web 应用程序
Requires=mariadb.service
[Service]
ExecStart=/usr/bin/myapp
[Install]
WantedBy=multi-user.target
在这种情况下，如果 mariadb.service 启动失败或被手动停止，systemd 也会停止 myapp.service。如果您尝试启动 myapp.service 并且 mariadb.service 没有运行，systemd 将首先尝试启动 mariadb.service。如果 mariadb.service 失败，myapp.service 将不会启动。
Wants=
Wants= 指令定义了一个较弱的、可选的依赖关系。如果单元 A Wants= 单元 B，systemd 在启动单元 A 时会尝试启动单元 B，但即使单元 B 启动失败或未运行，单元 A 仍会激活。这对于那些可以从另一个服务中受益但可以独立运行（也许功能有所减少或有警告）的服务非常有用。
示例：
假设一个监控代理（monitoring-agent.service）可以在没有特定日志服务（app-logger.service）的情况下运行，但最好能有该服务。monitoring-agent.service 单元文件可能如下所示：
[Unit]
Description=监控代理
Wants=app-logger.service
[Service]
ExecStart=/usr/bin/monitoring-agent
[Install]
WantedBy=multi-user.target
在这里，当 monitoring-agent.service 被激活时，systemd 将尝试启动 app-logger.service。然而，如果 app-logger.service 启动失败，monitoring-agent.service 仍将继续成功启动。
Requires= 与 Wants=
Requires=: 强依赖关系。如果所需的单元失败，依赖的单元也会失败或停止。Wants=: 弱依赖关系。依赖的单元会尝试启动被期望的单元，但即使它失败也会继续进行。
重要的是要注意，Requires= 暗示了 Wants=。如果一个单元需要另一个单元，它也隐式地期望它。
排序指令：After 和 Before
虽然 Requires 和 Wants 定义了 什么 需要运行，但 After 和 Before 定义了单元相对于彼此 何时 启动。这些指令控制系统启动过程或按需激活单元期间的操作顺序。它们通常与依赖指令结合使用。
After=
After= 指令指定当前单元应在列出的 After= 中的单元成功激活 之后 才启动。这确保了在依赖服务开始其自身的启动序列之前，先决条件服务已经启动并运行。
示例：
一个依赖网络的应用程序服务（custom-network-app.service）应该在网络完全配置 之后 才启动。这通常通过确保它在网络目标（network.target）之后启动来处理。
[Unit]
Description=自定义网络应用程序
Requires=network.target
After=network.target
[Service]
ExecStart=/usr/bin/custom-network-app
[Install]
WantedBy=multi-user.target
在此配置中，systemd 将确保在尝试启动 custom-network-app.service 之前 network.target 已激活。如果 network.target 尚未准备好，custom-network-app.service 将被推迟。
Before=
Before= 指令指定当前单元应在 Before= 中列出的单元 之前 启动。这对于需要在关机期间 在 其他服务之后停止，或需要在某些服务 之前 启动以提供环境的服务非常有用。
示例：
想象一个场景，邮件服务器（postfix.service）需要在任何可能发送电子邮件的用户界面服务之前运行。您可以使用 Before= 来确保 postfix.service 尽早启动。
[Unit]
Description=Postfix 邮件传输代理
# ... 其他指令，如 Conflicts=
Before=user-session.target
[Service]
ExecStart=/usr/lib/postfix/master
[Install]
WantedBy=multi-user.target
此设置尝试在 user-session.target 的任何部分开始启动 之前 启动 postfix.service。同样，在关机期间，如果 postfix.service 具有相应的 After=user-session.target，它将是最后被停止的服务之一。
After= 与 Before=
After=: 保证列出的单元在当前单元启动 之前 处于活动状态。Before=: 保证当前单元在列出的单元 之前 启动。
理解 After= 和 Before= 是相辅相成的非常重要。如果您希望单元 A 在单元 B 之后启动，并且单元 B 在单元 A 之后启动，您通常会在单元 A 中使用 After=B 和在单元 A 中使用 Before=B。这创建了一个严格的顺序：A 启动，然后 B 启动。对于相反的情况，B 启动，然后 A 启动。在排序时，指定您的单元 之后 应该发生什么，而不是您的单元 之前 应该发生什么，通常更直观。例如，要确保服务在网络之后启动，您会向服务添加 After=network.target。如果您希望服务在关机目标之前启动，您将使用 Before=shutdown.target。
组合指令以实现稳健的配置
在实际场景中，您通常会将这些指令组合起来以创建复杂的依赖图。multi-user.target 是一个常见的目标，表示系统已准备好进行多用户操作。许多服务被配置为 WantedBy=multi-user.target 和 After=multi-user.target（或者更精确地说，After=basic.target 和 After=getty.target 等，multi-user.target 依赖于它们）。
常见模式：
一个需要数据库并且应该在网络配置 之后 启动的服务可能如下所示：
[Unit]
Description=我的应用程序服务
Requires=mariadb.service
Wants=other-optional-service.service
After=network.target mariadb.service
[Service]
ExecStart=/usr/local/bin/my_app
[Install]
WantedBy=multi-user.target
模式解释：
Requires=mariadb.service: 保证mariadb.service必须运行，my_app.service才能正常工作。如果mariadb.service失败，my_app.service将停止。Wants=other-optional-service.service: 尝试启动other-optional-service.service，但即使它失败，my_app.service也会继续启动。After=network.target mariadb.service: 确保my_app.service仅在network.target和mariadb.service成功激活 之后 才启动。这对确保数据库可访问和网络就绪至关重要。WantedBy=multi-user.target: 启用时（systemctl enable my_app.service），此指令会添加一个符号链接，以便系统达到multi-user.target状态时启动my_app.service。
高级注意事项和最佳实践
WantedBy与RequiredBy: 与Wants与Requires类似，WantedBy是弱排序，而RequiredBy是强排序。大多数服务使用WantedBy=multi-user.target。Conflicts=: 此指令指定不应与当前单元并发运行的单元。如果当前单元启动，冲突的单元将被停止，反之亦然。- 传递依赖关系: 依赖关系是传递的。如果 A 需要 B，B 需要 C，那么 A 间接需要 C。Systemd 会自动处理这些链。
Condition*=指令: 使用ConditionPathExists=、ConditionFileNotEmpty=、ConditionVirtualization=等，使单元激活以系统状态为条件，进一步增强稳健性。- 使用
systemctl list-dependencies <unit>: 此命令对于可视化单元的依赖树（包括直接和间接依赖）非常有价值。 - 使用
systemctl status <unit>: 在进行配置更改后，务必检查服务的状态。它通常会显示失败原因，包括依赖问题。 - 避免循环依赖: 虽然 systemd 会尝试解决它们，但直接的循环依赖（
A Requires B、B Requires A）可能导致启动循环或失败。仔细设计您的依赖关系以避免这种情况。
结论
掌握 systemd 的依赖关系和排序指令是管理 Linux 服务的任何人的基础。通过正确使用 Requires、Wants、After 和 Before，您可以构建能够可靠启动并避免竞态条件等常见陷阱的弹性系统。理解强依赖和弱依赖之间，以及“什么”和“何时”之间的细微差别，可以实现对服务生命周期的精确控制，从而带来更稳定和可预测的系统行为。始终使用 systemctl status 和 systemctl list-dependencies 彻底测试您的配置，以确保您的服务按预期进行编排。