[systemd-devel] Requires and After
Zbigniew Jędrzejewski-Szmek
zbyszek at in.waw.pl
Wed Jan 2 08:51:29 UTC 2019
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
More information about the systemd-devel
mailing list