我有一个 systemdfw.service单元文件，这是以下要求networking.service：
# systemctl show networking -p Requires
Requires=system.slice fw.service
#
当networking.service处于该active状态并且我执行systemctl stop fw然后几秒钟后systemctl start fw，然后networking.service停留在该inactive (dead)状态。但是，当networking.service处于active状态并且我执行时systemctl restart fw，也会networking.service重新启动。
这是预期的行为吗？我认为systemctl restart基本上是systemctl stop紧随其后systemctl start，因此systemctl start也应该启动networking.service.
答案1
restartstop与+类似start，但并不相同。 服务管理器restart内部对工作的处理方式有所不同systemd。它不是systemctl界面中的简单便利功能。[*]
从这个具体行为来看，当前版本的man systemd.unit. （至少在我的安装中systemd-239）。
的行为stop已记录在案。并且行为start也与文档一致。没有明确记录的是 到restart所需单元的传播fw.service。但是，我在另一种类型的依赖关系中看到了有关它的提示：
部分=
配置类似于 的依赖关系
Requires=，但仅限于停止和重新启动单元。当 systemd 停止或重新启动此处列出的单元时，操作将传播到该单元。请注意，这是一种单向依赖关系 - 对此单位的更改不会影响列出的单位。
提示是 ifPartOf=是 的有限子集Requires=，则Requires=会执行所有PartOf=操作。所以这包括传播重启。
如果networking.service不想在第一步中停止，您可以替换Requires=fw.service为Wants=fw.service。但我认为Requires=是故意使用的，以尝试确保在防火墙规则未激活的情况下永远不会激活网络。
您可能希望重新启动按顺序进行，以便在没有激活的情况下networking.service永远不会激活，假设它也设置了 ......我还没有确认这就是实际发生的情况。 （如果这是您的希望，我建议您根据除此答案之外的其他权威机构进行验证:-)。fw.serviceAfter=fw.service
如果你真的愿意，我想你可以设置Wants=networking.service，fw.service即使networking.service已经Requires=fw.service。这是可能的，因为这些依赖关系并不意味着特定的顺序。我认为只有当您的系统中存在冲突时，您才会遇到“依赖循环”问题。订购依赖项 -After=和Before=设置。
[*] 例如systemd-logind是旨在可重新启动，并安排systemd在重新启动时保持某些关键文件打开。但如果您只stop登录，打开的文件就会丢失。 （据我所知，重新启动 systemd-logind 仍然会破坏 Xorg 或 Wayland 的每个当前版本，但您可以看到systemd代码处理不同的想法restart:-P）。