Re: ntpdate from cron -- DON'T DO THAT! - more
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
63.192.96.2 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.
That machine is running DNSmasq which is setup to read
/etc/ppp/resolve.conf and detect any changes (I don't think the DNS
machines changes, though). The machine emails me with its IP and DNS
config every time ppp comes up, which is how I know where to find the
machine when its IP changes.
>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.
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.
Thanks for the help,
--
Bill Moseley
mailto:moseley@hank.org
Reply to: