Systemctl 单元在“Requisite”上失败，但仍执行“ExecStart”命令

首先，请注意，在 systemd 中，需求依赖关系和顺序依赖关系是正交的。一个单元可以对另一个单元有弱/中等/强需求（Wants、Requires、Requisite等），但顺序必须使用Before/单独指定After。可以这样想：

• Wants=foo：当我开始时，foo也要求开始，但我并不真正关心它会发生什么。
• Requires=foo：当我启动时，foo也请求启动，如果foo的启动失败，则认为我的启动也失败，而不管对我的启动所采取的实际操作的状态如何。
• Requisite=foo：当我启动时，foo必须已经启动。如果没有，则认为我的启动失败，无论对我的启动采取的实际操作的状态如何。

因此，我可以拥有服务 A 和RequiresB，但可能有 B 的排序Before。当 B 正在做一些可以独立于 A 完成的一般性事情时，可能会出现这种情况，但 A 总是希望 B 在 A 启动后再做那件事。

特别是对于Requisite，文档特别建议将其与以下一起使用After：

因此此设置通常应与 结合使用After=，以确保该单元不会先于其他单元启动。

第二件要理解的事情是，作业和单元在 systemd 中是独立但相关的概念。有关更多信息，请参阅例如此答案或此答案。因此，当文档说：

然而，如果这里列出的单元尚未启动，它们将不会被启动，并且该单元的启动将立即失败。

这意味着该单元的启动工作将失败。但实际启动将继续进行。其工作方式如下：

1. 您运行systemctl start foo，或者其他导致foo启动的操作（例如，另一个单元、目标等的依赖）。
2. 然后 systemd 创建一个作业来启动该单元。
   1. 它向依赖单元发出有关其状态的查询。
   2. Requisite[在 (5) 之前的某个时间] 对非活动单元的查询导致作业状态设置为失败。
3. Systemd 等待任何按Before顺序排列的单元的作业。
4. 如果排序中没有任何内容失败（即Required或Requisite更严重），则它将继续实际运行ExecStart*命令。请注意，这意味着如果排序中它之前没有其他作业，则systemd 将立即继续执行此步骤。
5. 它报告作业的状态。
   1. Requisite如果某个单元未处于活动状态或者由于其他一系列原因（例如实际运行命令失败等），此操作将会失败。

为了使 (2.1) 中的检查对 (4) 中的命令执行有任何意义，systemd 应该在 (3) 中考虑一个顺序。在本例中，没有。

引用Lennart Poettering 的话：

没有 After= 的 Requisite= 是没有意义的。您将检查排入队列以确保某个单元已正确启动，但随后不等待检查结果，而是允许您放置该单元立即启动……