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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
