On Tuesday 27 July 2004 19:20, Rick Stevens wrote: [...] >ntpdate drags your machine kicking and screaming into compliance > with your NTP servers RIGHT NOW, while ntpd KEEPS it current. If > ntpd has to pull the machine into compliance, it does it just a > little bit at a time so it may take quite a while for it to get it > synchronized. Once the clock is synched, ntpd will keep it > synched. > >Think of ntpdate as a "rapid charger" on your clock, while ntpd is a >"trickle charger". Another analogy is ntpdate is a sledge hammer > (get the grunt work done), ntpd is a jewler's mallet (do the fine > tuning). > >Ideally, you use ntpdate once (normally at boot), and have ntpd run > in the background. That's what the startup scripts do. Unless you are keeping your hw clock on zulu time, Rick. Then a crash recovery sets the system clock 5 hours ahead of time because the shutdown portion of the script wasn't run. My solution is to make a copy of my updateclock script, which uses 'ntpdate -s -p 2' as the first argument, and a randomly selected server from a list of nearly 40 as the second argument. I call this one startclock, put it in rc.local and it has 'ntpdate -s -p 2' as its 1st argument. It seems to work here, and I just did it, so on the next crash recovery reboot I do, maybe I'll get the right time instead of 5 hours in the future, which gives gcc a huge tummy ache. Steven Hawking tells us thats not possible anyway :) -- Cheers, Gene There are 4 boxes to be used in defense of liberty. Soap, ballot, jury, and ammo. Please use in that order, starting now. -Ed Howdershelt, Author Additions to this message made by Gene Heskett are Copyright 2004, Maurice E. Heskett, all rights reserved.
