system clock is too slow

[Gene Heskett]

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.