On Aug 1, 2016, at 6:32 AM, Kurt Roeckx <k...@roeckx.be> wrote: >> >> The DHCPACK that assigns the IP address to the interface occurs during the >> middle of ntpd's startup, so two of three pool statements get failed DNS. >> The third one succeeds, so ntpd gets some servers, but not all the servers >> it's configured for. >> > > It looked to me like it was working. It says that it was a > temporary failure, and as far as I know it will retry it in that > case. > > Also not that ntpd has some weird logic of how many servers it's > using when using "pool", and it's probably not using it from all > the pools. You can set the maximum higher using "tos maxclock > XX". > > I was under the impression that when using "server" and getting > a permanent DNS error it would give up on it but that with a > temporary error it will retry. And that with pool it keeps > retrying, but I'm not sure about that. > > Anyway, that it's a temporary or permanent error depends on what > glibc returns, and I've been trying to get that fixed for years. > > > Kurt
Thanks, Kurt! I understand your frustration. Fragility of ntpd in the presence of DNS errors is important, and it should be fixed. But it’s not the point I was trying to make with these bug reports. My point is that whole thing could be avoided if systemd would wait to start ntpd and ntpdate until *after* the network interface has been *fully* initialized. If I understood more about the details of how systemd orders such things, I might be able to come up with a patch. But, sadly, every time I try to understand that aspect of systemd, I wind up in a maze of twisty little man pages and wiki references, all alike… /-: Rick
