"systemctl start“不启动反向依赖单元，而"systemctl重新启动”启动。

Question

我有一个systemd fw.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。

Answer 1

restart类似于stop+start，但并不完全相同。restart作业在systemd服务管理器中被不同对待。在systemctl接口中，它不是一个简单方便的特性。

从这个特定的行为来看，它没有在当前版本的man systemd.unit中显式地记录下来。(至少在我安装systemd-239时是这样的)。

stop的行为记录在案。start的行为也与文档一致。没有显式记录的是将restart传播到需要fw.service的单元。但是，我在另一种依赖类型中看到了一个提示：

PartOf=配置类似于Requires=的依赖项，但仅限于停止和重新启动单元。当systemd停止或重新启动此处列出的单元时，该操作将传播到此单元。请注意，这是一个单向依赖-更改此单位不影响列出的单位。

提示是，如果PartOf=是Requires=的有限子集，那么Requires=将执行PartOf=所做的一切。因此，这包括传播重新启动。

如果networking.service真的不想在第一步被停止，您可以用Wants=fw.service代替Requires=fw.service。但我认为Requires=是故意使用的，目的是确保在防火墙规则未激活的情况下，您永远不会激活网络。

您可能希望重新启动是按顺序进行的，这样networking.service就不会在fw.service也是活动的情况下被激活，假设它也设置了After=fw.service ...I还没有确认这是实际发生的情况。(如果这是你的希望，我建议根据这个答案以外的一些权威进行核实:-)

如果您真的愿意，我认为您可以在fw.service中设置D27，即使networking.service有Requires=fw.service。这是可能的，因为这些依赖关系并不意味着特定的顺序。我认为，只有在排序依赖项( After=和Before=设置)中存在冲突时，“依赖循环”才会有问题。

例如，systemd-logind是打算重新启动，并与systemd安排在重新启动过程中保持某些关键文件处于打开状态。但是如果您只访问了stop logind，那么打开的文件就会丢失。(AFAIK重新启动systemd仍然破坏了Xorg或Wayland的每个当前版本，但您可以看到systemd代码对restart的处理方式不同:-P)。