A perhaps surprising consequence of
Requires dependencies in systemd
Oh right. This service restarted because I said 'Requires=rsyslog.service' & I updated rsyslogd (which restarted it). Moral: don't do that.
The systemd.unit manpage
tells you that this will happen if you read it carefully. In the
If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated.
When you or a package upgrade script does a '
rsyslog is first deactivated, which triggers the
deactivation of my service, and then it is reactivated, which
fortunately results in the reactivation of my service too
(because systemd is not completely moronic, regardless of what
people may think of it).
The important thing to remember here is that
Requires has two
effects. The first is that it forces the required unit to start on
boot (or activation of your unit) and will stop your unit from
starting if the required unit fails for some reason. So what I was
saying is 'my unit must have rsyslogd in order to start and work'.
The other, as we saw here, is that your unit will be deactivated
or restarted if its required unit fails or is restarted.
This restart behavior is not as crazy as it may sound. There are
services which are strongly linked and that don't recover transparently
from having their communication to a required service broken; one
traditional example is
In classical NFS, the various services that use SUNRPC registered
portmap exactly once, when they started. If
restarted, those registrations were lost and could not be re-established
short of restarting all the other services too. This is a perfect
fit for a systemd
(I believe this has been changed in modern SUNRPC code, for the obvious reason that it's kind of suboptimal.)
Unfortunately I don't believe that systemd has a form of requirement
that just does the initial boot time requirement stuff without the
'restart your service when a
Requires restarts' bit.
not quite it because it doesn't stop your unit from starting if its
requirement doesn't. It's thus more useful for dependencies that
you would really like to be running but you don't absolutely totally
Probably what I should do for this service is shift my requirement
over to the general
syslog.socket, although that's not currently
activated on my system and I'm not completely sure it's the right
(It turns out that SUNRPC is now officially called ONC PRC, presumably because 'Sun' is a trademark and no one wanted to embed a trademark in the name of an official standard that was theoretically supposed to be vendor-neutral.)