On Mo, 16.10.17 15:15, 林自均 ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
