[systemd-devel] Passive vs Active targets

Thomas HUMMEL thomas.hummel at pasteur.fr
Tue Feb 15 16:30:00 UTC 2022


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


More information about the systemd-devel mailing list