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 ...". Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
