[systemd-devel] Passive vs Active targets

[Lennart Poettering]

On Mo, 31.01.22 20:13, Thomas HUMMEL (thomas.hummel at pasteur.fr) wrote:

> Hello,
>
> I'm successully using systemd with some non trivial (for me!) unit
> dependencies including some performing:
>
>   custom local disk formatting and mounting at boot
>   additionnal nics configuration by running postscripts fetched from the
> network
>   Infiniband initialisation
>   NFS remote mounts
>   Infiniband remote mounts
>   HPC scheduler and its side services activation
>
> and I've read
> https://www.freedesktop.org/software/systemd/man/systemd.special.html
>
> Still I do not fully (or at all ?) understand the concept of passive vs
> active targets and some related points:
>
> The link above states :
>
> "Note specifically that these passive target units are generally not pulled
> in by the consumer of a service, but by the provider of the service. This
> means: a consuming service should order itself after these targets (as
> appropriate), but not pull it in. A providing service should order itself
> before these targets (as appropriate) and pull it in (via a Wants= type
> dependency)."
>
> And also :
>
> "Note that these passive units cannot be started manually, i.e. "systemctl
> start time-sync.target" will fail with an error. They can only be pulled in
> by dependency."
>
> Since my first look at a passive dependency was network.target which I
> indeed saw was pulled in by NetworkManager.service which ordered itself
> Before it and which I compared with the active network-online.target which
> pulls in the NetworkManager-wait-online.service I first deduced the
> following:
>
> 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.

> I thought that a passive target could be seen as "published" by the
> corresponding provider
> But this does not seems as simple as that:
>
> For one I see on my system that rsyslog.service also pulls in network.target
> (but orders itself After it and thus does not seeems to be the actual
> "publisher" of it as opposed the NetworkManager.service)

There might very well be wrong users of this, that use this the wrong
way around. We do not systematically review other people's unit files,
and hence there might be a lot of issues lurking.

Yes, rsyslog.service should definitely not pull in network.target. (I
am not sure why a syslog implementation would bother with
network.target at all, neither Wants= nor After= really makes any
sense. i.e. if people want rsyslog style logging but it would be
delayed until after network is up then this would mean they could
never debug DHCP leases or so with it, which sounds totally backwards
to me. But then again, I am not an rsyslog person, so maybe I
misunderstand what it is supposed to do.)

Anyway, it would be excellent to file a bug against the rsyslog
package and ask it to drop the deps.

> 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.

> 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.

not sure what rdma-ndd does, can't comment on that.

> Finally, my understanding is some passive targets are not to be taken for
> granted, i.e. they may not be pulled in at all and it is to the user to
> check it if actually is the case if he want to order a unit againt it. I'm
> not talking here about obvious targets we don't have because out of our
> scope (like not having remote mounts related targets if system is purely
> local) but some we could think we have but maybe not. For instance on my
> system I see remote-fs-pre.target pulled in by nfs-client.target but would
> be remote-fs-pre-target be pulled in (by who?) if I had only Infiniband
> remote mounts ?

remote-fs-pre.target should be pulled in by whoever wants to run
*before* any remote mounts (i.e. do Wants= + Before= on it). The remote mounts should only order
themselves *after* it, but not pull it in.

> So my question would revolve around the above points
>
> Can you help me figuring out the correct way to see those concepts ?

I think you mostly got things right but the services you listed are
simply buggy.

Lennart

--
Lennart Poettering, Berlin