Rick Moen said on Sun, 20 Jun 2021 13:15:13 -0700


># ntpd -gqc /dev/null server1.name.net server2.name.org
>server3.name.com
>
>Above will always work, provided system clock is within about 68 years
>of current time.
>
>Do _not_ use ntpdate any more. It doesn't work well.
>https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

Ugh!

My computer doesn't have sntp, nor does it have ntp-wait. My openntpd
doesn't have a -q. Meanwhile, the documentation you referenced says the
date should be set very well as early as possible and those requiring
an exact date delayed as late as possible. But that's still a race
condition. I could do the following as soon as the network and DNS are
running:

rm /tmp/ntpd.pid
openntpd -p /tmp/ntpd.pid -s

The preceding would block until hopefully the time is well set, adding
several seconds to the boot, which does no harm except it gives the
systemd fanboiz another silly marketing point. But if it failed to get
the time "well set", there's no way of knowing it.

It would be nice to put the openntpd run in a loop that tests for "well
set" time and quits when the time is well set. As it loops, it gives
the user the choice of ignore or abort or go into some sort of
diagnostic session. This implies that /dev/console would already have
to be running.

Dynasties later, when the boot runs the runit process manager, the
process manager for openntpd can kill the process identified with
/tmp/ntpd.pid, and restart ntpd as a supervised daemon.

SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques