Re: [chrony-dev] Bug -- interaction between ntpdate and chronyd at bootup -- will never sync up

[ray vantassle <rayvantassle@xxxxxxxxx>]

It's easy to duplicate.
ntpdate starts up this way:
NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org
2.debian.pool.ntp.org 3.debian.pool.ntp.org"
/usr/sbin/ntpdate $NTPSERVERS

It makes 4 queries to each of 16 servers, for a total of 64 queries.
That takes about 9.5 seconds.
(A bit of overkill -- but that's the config in the ntpdate package.)

At startup, ntpdate is invoked as a result of dhcp coming up or when
the network starts up, via a script in /etc/network/if-up.d/

/etc/init.d/chrony gets invoked about 2-3 seconds after ntpdate
starts, to bring up chronyd.

When all goes well (no overlap) it takes chronyd about 5 seconds from
the time the servers are marked "online" until it says "Selected
source ..."

Once you figure out what's going on -- which is *not* easy, since
timing bugs are a bitch -- it's not too hard to make a work-around.

One workaround is to get the time set very quickly early in startup.
Rdate will do that (under a second).  Or ntpdate will if you give it
only a few servers and -p1 option (about 2 seconds).   The timing
window is still there, but it doesn't usually happen.

My final workaround was to add a check in the putonline function of
/etc/init.d/chrony, after the "sleep 2":
    cnt=0
    while [ $cnt -le 50 ] ; do
        pidof ntpdate rdate >/dev/null || break
        sleep 1
        cnt=$(( $cnt + 1 ))
    done

This will delay the chronyd startup for up to 50 seconds, until
neither ntpdate nor rdate is running.

I went with rdate instead of ntpdate -- because without a RTC it is
important to set the clock as soon as possible, as early as possible
after bootup.  But that's not a chrony issue.

In chrony.conf, I put "makestep 1000 10".