On Sep 13, 2011, at 10:37 PM, Bryan Kadzban wrote: > Yes, but I think there's another way to accomplish this, without the > long delay inherent in using -q. If we can sync from the hardware clock > at boot time, then the user only has to manually adjust (or run ntpd -q > manually, and wait for it) whenever something else goes and changes the > hardware clock, or on first boot. > > If the system boots with a large discrepancy between the timeserver and > the kernel (as when the hardware clock is not UTC, or (?) you don't use > the HCTOSYS kernel compilation option), then ntpd -q does fix the issue. > But that extends the boot time by several seconds on every boot, when it > may or may not be necessary to do so. > > If the user can rely on a boot happening a short-enough time after a > shutdown (I can :-) ), then they can just save the system clock to the > hardware clock at shutdown time, restore it from there at boot, and (as > long as nothing else has changed the hardware clock in between) skip > running ntpd -q on each boot. It doesn't have to be perfect, it just > has to be less than the ntpd threshold. > > (And, of course, the clock-setting has to happen before the ntp script > runs.)
I wonder if you misread what I suggested... maybe? I don't use -q at all... ever, because it does just what you said, hangs the boot process by waiting for a response from an ntp server. I use -g alone which allows the first correction on startup to be large and then it runs silently in the background, but it doesn't wait like adding -q does. And I do (personally) sync from the hardware clock at boot time. My ntp script depends on the setclock one, so that's always first. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
