Andrew Benton wrote: > Matthew Burgess wrote: > >> I think the solution is to move the initial time-sync operation out of >> the bootscript and into the configuration section of NTP (obviously >> with enough explanation as to why we need to do this and why it should >> be a one-time operation, but faulty hardware like a dodgy CMOS battery >> might require it to be rerun). This should avoid the problem of the >> clocks being too far out that ntpd refuses to sync them. It then >> allows `ntpd' to start up nice and quickly during the boot process as >> it operates in its normal gradual adjustment mode. >> > > The fly in the ointment here is if you're unfortunate enough to share > you computer with someone who likes to boot into windows. Windows likes > to reset the system clock to local time which can be hours different to > UTC. Ntp then quits without trying to correct it as the difference is > too large. For those unfortunate souls, the ntp -g option may be the > best compromise >
Two thoughts. Firstly, delete the windows partition in the bootscrips - eventually they will get the message :-) Second, the real need is for a reasonably acurate clock by the time that services (such as a web server or mta) start. This is one of the reasons why I moved away from starting any of these with bootscripts and now use runit (daemontools-without-the-Bernstein, it's not necessary to make it init for this). The point is to get the system up first, then synchronise the watches, then start the services that depend on accurate clocks. If this acutally takes a couple of minutes, that's what it takes - choose your ntp service with care, there are plenty to choose from. You can't do starting a time-dependent service before the clock is set. Despite it being deprecated, ntpdate is useful just because it gets the local clock near-sync. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
