Re: ntpdate from cron -- DON'T DO THAT! - more
On Sat, 21 Dec 2002, Bill Moseley wrote:
> At 04:27 PM 12/21/02 -0800, Alvin Oga wrote:
> >> daemon.log:Dec 16 02:20:14 burn ntpd_initres: couldn't resolve
> `ntp1.mainecoon.com', giving up on it
> >> daemon.log:Dec 21 14:30:29 burn ntpdate: step time server
> 188.8.131.52 offset 3203.797781 sec
> >sounds like you need to fix your dns ?? ( at least it found one )
> >( and/or hardcode it ( the ntpservers in /etc/hosts ) for quickie tests )
> I think that's not due to wrong server, rather to just plain loss of
> connection. Still, once it "gives up" I wonder if it every tries again.
> Doesn't seem so from the logs. Network connections do go down once in a
sometimes dns takes a while... putting it in /etc/hosts saves some time
... but only for testing ... ( unless /etc/hosts is copied to all
machines to avoid some machines works and others die )
> >iirc, ntpd will not sync if you're more than 1000 seconds off... ntpdate
> >will resync... but you will need to resync your hwclock to the sw clock
> It would be nice if it logged that event. Still, it's hard to imagine that
> it would be off line long enough to get that far behind.
ntpdate only changes the sw clock .. not the bios clock ...
- you need to update the biosclock ( hwclock ) wehn you shutdown
properly... otherwise... the whole 3000sec off resyncing time
- i simply go to the bios and fix it... lot easier than reading lots of
man pages and which commands to use .. than xntpd can do its magic
> I wonder if running hwclock --systohc from cron would fix the problem. It
> may be that the machine is being restarted without a proper shutdown (and
> hwclock save), so that on restart it's reading a very slow hwclock.