> On Mar 14, 2019, at 1:04 AM, Richard Laager <rlaa...@wiktel.com> wrote:
>
> I forwarded your bug upstream:
> https://gitlab.com/NTPsec/ntpsec/issues/577
Hi!
I’m sorry to take so long getting back. I wanted to re-do my experiments in a
standard environment that your would be able to reproduce easily. Here are the
results.
The system is a Cubox-I4Pro (2 GB RAM, quad-core ArmHF processor)
The OS is fresh-out-of-the-box Debian Buster with a default “multi-user” text
console configuration (i.e. no GUI).
Things I have done to show the problem:
1) I modified the /etc/ntpsec/ntp.conf to use only two of the four available
“debian.pool.ntp.org” pools. In my original use-case, one of these pools would
be on the local intranet, while the other would be an internet pool to act as a
ballast incase the local intranet pool has problems.
2) I further modified the ntp.conf to have “tos minclock 7 minsane 5”. The
reason for this is to force it to use some servers from the “backup” pool to
allow a smooth transition in the above-mentioned failure case.
3) To monitor the behavior under this setup I run an “@reboot” cron job that
consists of the following shell sript:
================ cut here =================
#!/bin/bash
for i in `seq 1 130`
do
echo -n "$i "; date; /usr/bin/ntpq -pn ; /usr/bin/ntpstat
echo
sleep 30
done > /tmp/monitor.$$.out 2>&1
journalctl -b | egrep 'ntp|eth' > /tmp/journal.$$.out
================ cut here =================
I have attached copies of the monitor and journal output files from this script.
Hi-lights of the results from the monitor file:
at 02:34:27 the script starts as part of the reboot process. ntpsec has not
started yet.
by 02:34:58 (31 seconds later) ntpsec has started and we have contacted four
servers from one of the pools, but due to minsane=5 it is unable to
synchronize. Note that the time taken from the system’s hardware clock at
reboot is about a half second off from network time from these servers.
at 02:38:32 (about the 4 minutes mark) this situation has continued unabated.
The same four servers without any progress synchronizing. System time is still
a half second off from network time.
at 02:39:01 (29 seconds later) Something has happened to cause us to contact
another group of 4 servers. Also, the system clock has been stepped to pick up
the half-second.
at 02:39:32 (about the 5 minute mark) We’re starting to get results from the
(now) eight servers on our list, and we have finally achieved useful
synchronization.
Hi-lights of the results from the journal file:
at 02:34:27 ntpd starts. But DHCP hasn’t yet got an IP address for the
ethernet port.
at 02:34:30 the ethernet link comes up. In the next few seconds, ntpd
unsuccessfully tries to contact first 0.debian.pool.ntp.org, then
1.debian.pool.ntp.org (twice).
at 02:34:35 DHCP finally gets an answer and an IP address is assigned to the
ethernet port.
at 02:34:36 ntpd tries 1.debian.pool.ntp.org for a third time (ignoring
0.debian.pool.ntp.org for some reason) This time it succeeds and gets four
server addresses as we see in the monitor log at 02:34:58.
Nothing happens for about 4 and a half minutes.
at 02:38:52 ntpd tries 1.debian.pool.ntp.org again (still no mention of
0.debian.pool.ntp.org) and gets four different server addresses because the
timer at the DNS server expired and caused it to remix the server addresses.
at 02:38:58 ntpd steps the clock to pick up the missing half second.
Nothing happens for the next roughly 25 minutes, until the test period expires.
Observations:
The system spent it’s first 4.5 minutes of life with an unsynchronized clock.
ntpd never used the 0.debian.pool.ntp.org pool at all. It seems to have been
completely forgotten after the first failed attempt.
Conclusions (thinks I’d like to see in future versions):
As long as minsane or minclock are unsatisfied, I’d like to see it attempting
to use all the servers and pools at its disposal, not just the single most
recently seen one.
I’d also like to see it trying to contact DNS more frequently than once every
4.5 minutes.
Enjoy!
Rick
