Didier Kryn <kryn@???> writes:
> Le 18/04/2016 17:17, Rainer Weikusat a écrit :
>> Didier Kryn <kryn@???> writes:

[...]


>>> This can't work with the method of starting all services in the same
>>> time, in general, not specifically by systemd.
>> It absolutely can: This depends on how often the stub resolver in the C
>> library (or the systemd stub resolver) retries a query before giving
>> up.

[...]

>     ntpd running as a server can wait until the network is ready. But
> if you run it with the option -q, you expect a different behaviour,
> like, maybe, a quick termination.

"The network is ready" doesn't really mean anything (and ntpd certainly
doesn't wait for that). The originally reported problem was that the
names of some NTP servers of the PTB (German 'Physikalisch-Technische
Bundesanstalt') couldn't be resolved. Judging from the posted output,
the programm which tried to do this made 3 calls to a C library name
resolving routine, eg, gethostbyname or getaddrinfo. This C library
routine will create a corresponding DNS query message and send that to
the configured name server (or name servers) a couple of times and wait
for a certain amount of time after the last send for a reply to
arrive (compared to the time it takes a server to start, this will be a
large amount of time). If no reply is received during the resend and wait
interval, the library routine will return with an error. But whether or
not a reply will be received depends on a lot of 'moving parts' beyond
the computer which asked the query.

ntpd (when running as daemon) is more robust in face of transient
'network issues' (although not necessarily DNS-related ones, as it also
just resolves a name once) because it doesn't give up after a fixed and
relatively small amount of time has passed: It sends queries to other
servers in certain intervals and will use whatever replies it receives
in order to help with keeping the clock accurate.