Jeremy Huntwork wrote: > 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 misread both what you suggested, and the manpage when I had looked earlier. Sheesh. :-) Yes, -g seems like it should work fine if it's included in the ntpd daemonization command thing that the bootscript runs.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
