On 15/02/2022 11:52, Lennart Poettering wrote:
a) a passive target "does" nothing and serves only as an ordering checkpoint
b) an active target "does" actually something
Yes, you could see it that way.
Hello, thanks for your answer.
Yes, rsyslog.service should definitely not pull in network.target.
Ok so I this misguided me. Got it now
Then rpcbind.target seems to auto pull itself so without the Before ordering
we see in the NetworkManager.service pulling network.target example
Can't parse this.
Sorry, my mistake, forget about this.
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".
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.
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 ?
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 ?
Thanks for your help
--
Thomas HUMMEL
