On Tue, Feb 28, 2017 at 05:04:08AM +0000, Ben Hutchings wrote: > On Mon, 2017-02-27 at 19:30 -0800, Russ Allbery wrote: > > Ben Hutchings <b...@decadent.org.uk> writes: > > > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: > > > > Daniel Pocock <dan...@pocock.pro> writes: > > > > > However, at the time when I ran ntpdate, ntp was not running. I had > > > > > brought up the network manually due to an interface renaming issue on > > > > > the first boot. Maybe when somebody runs ntpdate in a scenario like > > > > > that the kernel is not sending the new date/time to the hardware > > > > > clock. > > > > Right, ntpdate for some reason doesn't set the flag to do this. > > > > > > [...] > > > There is a very good reason, which is that without continuous > > > adjustment the system clock cannot be assumed more stable than the RTC. > > > > If you've literally just synced the system clock to a remote NTP server, > > why could you not assume it was more accurate than the RTC? > > For that instant, sure, and ntpdate could follow-up the one-shot system > clock synch with a one-short RTC synch. But the kernel doesn't provide > a simple API for that, and it's easy enough to add "hwclock --systohc" > to a script right after "ntpdate ...".
If anything, having ntpdate call hwclock might make sense. Having ntpdate clear the unsynced flag doesn't make sense since it would start writing a time to the RTC each 11 minutes, and as Ben said you have no idea which of the 2 clocks is the most correct one. I can also understand that systemd doesn't set the clock for just the same reason. Either the clock is synched and it's written, or it's not suched, it's unknown which one is the most correct, and it's not written. Kurt
