[systemd-devel] Requires and After

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 02, 2019 at 07:14:10PM +1100, Michael Chapman wrote:
> On Wed, 2 Jan 2019, Olaf van der Spek wrote:
> > On Wed, Jan 2, 2019 at 4:22 AM James Feeney <james at nurealm.net> wrote:
> > > systemd has two different classes of "dependencies": 1) "activation" 
> > > dependencies, and 2) "ordering" dependencies.
> > >
> > > An activation dependency does not, a priori, have to obey any rules 
> > > about ordering.  There are not, automatically, any promises or 
> > > guarantees about in what order service units, for instance, might be 
> > > queued for execution, based upon a Requires= dependency.
> > >
> > > "Ordering" is an independent characteristic from "Activation".  
> > > "Activation" only promises to enqueue a unit, and then, only if the 
> > > unit is some kind of unit that can be "executed", such as a timer or 
> > > service unit.  In contrast, for instance, systemd is only a "passive 
> > > observer" of a device unit.  "enqueuing" a device unit for 
> > > "activation" would make no sense in this context.  A *service* unit 
> > > that *creates* a device unit could be enqueued for activation, but not 
> > > the device unit itself.
> > >
> > > If "A Requires B", and you don't like that "A" *might* get enqueued, 
> > > or get executed, before "B", then add an "ordering" dependency.  
> > > "Ordering dependencies", then, create guarantees about unit activation 
> > > *ordering*.
> > 
> > What good is an activation dependency without an ordering dependency?
> 
> 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.

> 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.

Zbyszek