[systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jan 02, 2019 at 07:14:10PM +1100, Michael Chapman wrote:
[...]
> > The problem is that it's not necessarily clear _which_ ordering dependency 
> > is required. systemd can't just assume one way or the other.
> > 
> > I have two services on my system, A.service and B.service, where A.service 
> > Wants=B.service but is ordered Before=B.service. The reason for this is 
> > that when I start A I want B to be automatically started too, but B cannot 
> > function without A being active.
> 
> But this really means that B.service should have After=A.service +
> Requires=A.service. Having A.service/start automatically imply B.service/start
> is just unnecessary magic.

In my particular case the magic is quite useful. Specifically, only _some_ 
of my systems need B.service. I don't want to have to think "on this 
system I need to start A, but on this system I need to start B and let it 
automatically start A".

I could imagine also it'd be useful if B.service had some ConditionFoo= 
directive, since that won't prevent A.service from being started even if 
it had Requires=B.service.

> > So here's an example where the activation dependency is essentially 
> > "opposite" that of the ordering dependency.
> > 
> > As you've pointed out, Requires= a bit of a strange case. If I change the 
> > above situation to use Requires= instead, and if B subsequently exits or 
> > fails, A would be stopped. I don't have an immediate use for that, but I 
> > think it's a bit presumptuous to assume that no use could possibly exist.
> > 
> > I think there's use in having Wants= and Requires= work similarly to each 
> > other, in that they are both orthogonal to ordering dependencies. It would 
> > be odd to have only one imply an ordering dependency.
> 
> If we made Requires= imply After=, it'd be a "default" dependency, so an
> explicit Before= would prevent the After= from being added. (This is the same
> as for .wants/ and .after/ directories: an ordering dependency is added, if
> DefaultDependencies=yes, and if Before= was not added to invert the ordering.)
> So a "reverse" orderding like you describe would still be possible.

OK. I'm still not convinced the inconsistency is worth it (it's hard 
enough explaining the existing logic, now we're thinking about adding 
_more_ exceptional cases!), but if it can be overridden it's not too bad.