[pkg-ntp-maintainers] Bug#833136: Bug#461461: This bug is still present -- change to systemd did not fix it!

[Rick Thomas]

On Aug 1, 2016, at 6:32 AM, Kurt Roeckx <kurt at 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