[systemd-devel] Passive vs Active targets

[Lennart Poettering]

On Di, 15.02.22 17:30, Thomas HUMMEL (thomas.hummel at pasteur.fr) wrote:

> > > Also, it seems that there are more than one way to pull in a passive
> > > dependency (or maybe several providers which can "publish" it). Like for
> > > instance network-pre.target wich is pulled in by both nftables.service
> > > and/or rdma-ndd.service.
> >
> > nftables.service should pull it in and order itself before it, if it
> > intends to set up the firewall before the first network iterface is
> > configured.
>
> It makes sense but I'm still a bit confused here : I thought that a unit
> which pulled a passive target in was conceptually "publishing it" for *other
> units* to sync After= or Before= it but not to use it itself. What you're
> saying here seems to imply that nftables.services uses itself the passive
> target it "publishes".

A passive unit is a sync point that should be pulled in by the service
that actually needs it to operate correctly. hence: ask the question whether
networkd/NetworkManager will operate only correctly if nftables
finished start-up before it? I think that answer is a clear "no". But
the opposite holds, i.e. nftables only operates as a safe firewall if
it is run *before* networkd/NM start up. Thus it should be nftables
that pulls network-pre.target in, not networkd/NM, because it matters
to nftables, and it doesn't to networkd/NM.

> Or maybe it is the other way around : by pulling it *and* knowing that
> network interface is configured After= nftable.service is guaranteed to set
> up its firewall before any interface gets configured.

So yeah, passive units are mostly about synchronization, i.e. if they
are pulled in they should have units on both sides, otherwise they
make no sense.

> > not sure what rdma-ndd does, can't comment on that.
>
> My point was more : is it legit for 2 supposedly different units to pull in
> the same passive target ?

Yes. If there are multiple services that really want to be started before
some other set of services are started, then the passive target is a
great way to generically put a synchornization point between them. It
can be any set of services before, and any set of services after it.

> Anyway both point above seem to confirm that one cannot take for granted
> that some passive target will be pulled in, correct ? So before ordering
> around it one can make sure some unit pulls the checkpoint ?

Yeah, that's the idea: passive units are mostly synchronization
points, that allow lose coupling for ordering things: for generically
ordering stuff before and after it without actually listing the
servicess explicitly on either side.

Lennart

--
Lennart Poettering, Berlin