“systemctl start” does not start a reverse dependent unit while “systemctl restart” does

Question

I have a systemd fw.service unit file which is a requirement for networking.service:

# systemctl show networking -p Requires
Requires=system.slice fw.service
# 

When the networking.service is in the active state and I execute systemctl stop fw and then few seconds later systemctl start fw, then the networking.service stays in the inactive (dead) state. However, when the networking.service is in the active state and I execute systemctl restart fw, then the networking.service is also restarted.

Is this an expected behavior? I thought that systemctl restart is basically systemctl stop followed by systemctl start and thus systemctl start should also start the networking.service.

Answer 1

restart is similar to stop+start, but it is not identical. restart jobs are treated differently inside the systemd service manager. It is not a simple convenience feature in the systemctl interface.[*]

Looking at this specific behaviour, it is not documented explicitly in the current version of man systemd.unit. (At least in my install of systemd-239 ).

The behaviour with stop is documented. And the behaviour with start is also consistent with the documentation. What is not explicitly documented, is the propagation of the restart to the unit which required fw.service. However, I see a hint about it in another type of dependency:

PartOf=

Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units.

The hint is that if PartOf= is a limited subset of Requires=, then Requires= will do everything that PartOf= does. So this includes propagating restarts.

If networking.service did not really want to be stopped in the first step, you could replace Requires=fw.service with Wants=fw.service. But I assume Requires= was used deliberately, to try and make sure you never activate your network without your firewall rules being active.

You might hope the restarts are sequenced such that networking.service is never activated without fw.service also being active, assuming it also set After=fw.service ...I have not confirmed that this is what actually happens. (If this is your hope, I would recommend verifying it based on some authority other than this answer :-).

If you really want to, I think you can set Wants=networking.service in fw.service, even though networking.service has Requires=fw.service. This is possible because these dependencies do not imply a specific order. I think you can only have problems with "dependency loops" if you have a conflict in your ordering dependencies - the After= and Before= settings.

---

[*] For example systemd-logind is intended to be restartable, and arranges with systemd to keep certain critical files open across the restart. But if you only stop logind, the open files are lost. (AFAIK restarting systemd-logind still breaks every current version of Xorg or Wayland, but you can see the idea that systemd code is treating restart differently :-P).