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:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
