[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ntpdate from cron -- DON'T DO THAT! - more

hi ya

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[307]: couldn't resolve
> `ntp1.mainecoon.com', giving up on it
> >> daemon.log:Dec 21 14:30:29 burn ntpdate[6612]: step time server
> 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
> while.

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
	starts again

- 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

c ya

> 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.

Reply to: