The purpose of this mechanism is to ensure that ordering relationships can be made but do not take effect unless necessary.
time-sync.target is an ordering milestone. All of the services that provide "time synchronization" specify that they are
time-sync.target, so that the target only becomes ready once "time synchronization" is in effect. All of the services that need "time synchronization" to be in effect when they run specify that they are
If the latter also had a
Wants relationship to that target, then they would always end up being ordered by it, as it would always be included in the set of things that are put into order.
This is seen as being suboptimal in the case where there is in fact no concrete "time synchronization" service; and the thinking of the systemd people is that such ordering should not be in effect in such a case. Rather, services should be ordered as if
time-sync.target were not there, allowing some of them to be started much earlier if that is their "natural" position without the milestone.
The solution is for
time-sync.target to actually not be there. It isn't wanted by the services that expect to start after time synchronization is available. So it does not exist in the set of ordered things if only those services are started. It is only brought into the set if an actual "time synchronization" service is started, with that (rather than the client services) having the
Wants relationship that brings it in.
Targets do not necessarily have to be collections of services. They can also be ordering milestones.
There are a fair number of such pure milestones, in systemd and elsewhere. The
name-services target in the nosh toolset's service bundle collection is a similar pure ordering milestone.
- Jonathan de Boyne Pollard (2018).
system-control. nosh Guide. Softwares.