[systemd-devel] Requires and After

[Michael Chapman]

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.

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.

Moreover, we can't simply change what systemd does here: it would be a 
backward-incompatible change. We don't want that.