[systemd-devel] Why do passive target units have to exist?
Lennart Poettering
lennart at poettering.net
Tue Oct 24 08:45:00 UTC 2017
On Mo, 16.10.17 15:15, 林自均 (johnlinp at gmail.com) wrote:
> Hi folks,
>
> I am reading systemd documents, and I find passive target units a little
> bit confusing.
>
> Take "network.target" for example:
>
> "systemd-networkd.service" specifies "Wants=network.target" and
> "Before=network.target". That effectively makes starting
> "systemd-networkd.service" brings up both "systemd-networkd.service" and
> "network.target", and make sure that "network.target" is active after
> "systemd-networkd.service" being active. It also implies that the shutdown
> order is correct: "network.target" will be stopped before
> "systemd-networkd.service". Everything is fine.
>
> What if we use an active target unit to achieve all this? Can we specify a
> "WantedBy=network.target" in "systemd-network.target"? So that we can
> enable "systemd-network.service" (which makes a symbolic link in the
> "network.target.wants" directory) and start "network.target" to pull in
> "systemd-networkd.service". That also makes sure "network.target" is active
> after "systemd-networkd.service" because of the target unit default
> dependencies. And shutdown order will be correct too.
>
> The only difference I can tell is the units to start. With a passive
> "network.target", we start "systemd-networkd.service". With an active
> "network.target", we start "network.target".
>
> Is there any benefits of passive target units over active target units?
We generally try to minimize synchronization points. "network.target"
is one, and we don't want it around if there's no reason to have
it. The more synchronization points you have the more serial your boot
becomes.
The logic hence is: if there's not networking stack then there's no
reason for services to synchronize before or after it, and thus it's
the networking stack that pulls in network.target and not its
consumer, if you so will.
Does that make sense?
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list