Date: Mon, 17 Jan 2005 18:09:15 -0600 From: John <john@starfire.mn.org> To: Rob <spamrefuse@yahoo.com> Cc: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: ntpd problems since upgrading to 5.3 Message-ID: <20050117180915.B30253@starfire.mn.org> In-Reply-To: <20050117124900.B28640@starfire.mn.org>; from john@starfire.mn.org on Mon, Jan 17, 2005 at 12:49:00PM -0600 References: <200501112100.10680.imoore@picknowl.com.au> <41E3E160.7030107@yahoo.com> <20050117122248.A28640@starfire.mn.org> <20050117124900.B28640@starfire.mn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 17, 2005 at 12:49:00PM -0600, John wrote: > On Mon, Jan 17, 2005 at 12:22:48PM -0600, John wrote: > > On Tue, Jan 11, 2005 at 11:23:28PM +0900, Rob wrote: > > > Ian Moore wrote: > > > > Hi, > > > > Ever since I upgraded from 5.2.1-RELEASE to 5.3-RELEASE, I've been getting the > > > > following error on boot: > > > > ntpd[380]: bind() fd 7, family 28, port 123, addr fe80:1 > > > > ::204:61ff:fe46:be89, in6_is_addr_multicast=0 flags=0 fails: Can't assign > > > > requested address > > > > > > > > ntpd seems to be working from what I can see in it's log file, but I can't do > > > > anything with ntpq to check it. > > > > Wether I run it as my normal user or as root, running ntpq -p always gives: > > > > ntpq: write to localhost.foo.com failed: Permission denied > > > > > > > > > > I had once a problem with ntpd, when also running named. Some hostname > > > resolution failed, because the servers were started in the wrong order. > > > Are you also running named? > > > > > > > Here is my ntpd entries in rc.conf: > > > > ntpd_enable="YES" # Run ntpd Network Time Protocol (or NO). > > > > ntpd_program="/usr/sbin/ntpd" # path to ntpd, if you want a different one. > > > > ntpd_flags="-c /etc/ntp.conf -p /var/run/ntpd.pid" > > > > > > I use: > > > ntpd_enable="YES" > > > ntpd_flags="-g" > > > > > > > and the contents of ntp.conf: > > > > server 210.48.130.204 > > > > server augean.eleceng.adelaide.edu.au > > > > driftfile /var/db/ntpd.drift > > > > logfile /var/log/ntpd > > > > > > And here I use: > > > driftfile /var/db/ntpd.drift > > > pidfile /var/run/ntpd.pid > > > server nr1.time.server > > > server nr2.time.server > > > server nr3.time.server > > > > OK - this is interesting! > > > > I have identical ntp.conf files on my 5.2.1 system and my 5.3-STABLE > > system. Guess what? The 5.2.1 system works, and the 5.3-STABLE system > > doesn't. Not only that, but the clock on my 5.3-STABLE system is RACING. > > It is going at almost twice as fast as real time. > > > > Here's the ntp.conf file: > > # stratum 3 time server > > server 192.168.1.1 > > > > driftfile /var/db/ntp.drift > > > > In both cases, name resolution is working. On the 5.2.1 system, ntpdc > > shows: > > ntpdc> peers > > remote local st poll reach delay offset disp > > ======================================================================= > > *dexter.starfire 192.168.1.52 3 64 377 0.00073 0.060184 0.00093 > > ntpdc> > > > > On the 5.3-STABLE system, it ntpdc shows: > > ntpdc> peers > > remote local st poll reach delay offset disp > > ======================================================================= > > =dexter.starfire 192.168.1.53 16 64 0 0.00000 0.000000 0.00000 > > ntpdc> > > > > This shows that DNS is working fine, as the remote name is being > > correctly resolved. (I know I'm showing some of my IP numbers, but > > it's all NAT). > > > > I'm afraid something is broke! > > > > Oh, and ntpdate works on the 5.3 system just fine (when ntpd isn't > > running, of course). > > > > The system that is running 5.3-STABLE was a good time keeper before > > this update (4.9-STABLE). > > OK. An update. > > I ran > "ntpdate 192.168.1.1 ; ntpdate 192.168.1.1 ; ntpdate 192.168.1.1" and > suddenly, I'm keeping time MUCH better! > > My current theory is that whatever is going wrong with adjkerntz, > it messed up the kernel time keeping adjustment, and when I ran ntpdate > close enough together that it was able to use adjtime rather than > stepping the time, that helped things out greatly. > > ntpd still doesn't work, but my system is keeping time much better! > MUCH better! Stranger and stranger. Well, since ntp kept RUNNING, I neglected to check the logs. Shame on me. This is what goes into the log: Jan 17 18:04:29 pearl ntpd[838]: ntpd 4.2.0-a Sun Jan 9 10:58:59 CST 2005 (1) Jan 17 18:04:29 pearl ntpd[838]: bind() fd 7, family 2, port 123, addr 0.0.0.0,in_classd=0 flags=8 fails: Address already in use HOWEVER, when I do a netstat -na | grep "\.12" before running it, there is no matches. After running it (and getting the error, but it stays running, and non-functional), I get: udp4 0 0 192.168.1.53.123 *.* udp6 0 0 fe80:5::206:25ff.123 *.* udp6 0 0 fe80:4::1.123 *.* udp6 0 0 ::1.123 *.* udp4 0 0 127.0.0.1.123 *.* udp6 0 0 fe80:1::2d0:59ff.123 *.* udp6 0 0 *.123 *.* udp4 0 0 *.123 *.* I don't get it. It's almost like it's trying to start twice, or forking at the wrong time, or something. Those ports for listening look pretty resonable, but it doesn't work, and it gives that error message. Very odd. It's definitely broke. Who wants to send in the PR? -- John Lind john@starfire.MN.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050117180915.B30253>