Re: ntpd problems since upgrading to 5.3 - found the problem!
On Wed, 19 Jan 2005 00:54, Lowell Gilbert wrote: Ian Moore [EMAIL PROTECTED] writes: I've just realised I'm not running a name server at all on my 5.3 system. I have 4.9 installed on this computer too I'd set up the caching server on it, I guess I forgot that step when I installed 5.3. I'll set it up see that makes any difference. Make sure to switch to using domain names that aren't in use by other people... [A common convention is to use .lan or .local as the top-level domain if you are using non-public domain names.] Thanks, I hadn't thought of using a non-existant top level domain. I've changed the hostname to daemon.foo.lan and now localhost.foo.lan resolves to 127.0.0.1 as it should. Unfortunately, I still get the same response form ntpq: daemon:~ % sudo ntpq -p ntpq: write to localhost.foo.lan failed: Permission denied Even with my firewall disabled I get this response. Cheers, -- Ian Moore GPG Key: http://homepages.picknowl.com.au/imoore/imoore.asc pgpaXjoKVcfku.pgp Description: PGP signature
Re: ntpd problems since upgrading to 5.3 - found the problem!
Ian Moore [EMAIL PROTECTED] writes: On Wed, 19 Jan 2005 00:54, Lowell Gilbert wrote: Ian Moore [EMAIL PROTECTED] writes: I've just realised I'm not running a name server at all on my 5.3 system. I have 4.9 installed on this computer too I'd set up the caching server on it, I guess I forgot that step when I installed 5.3. I'll set it up see that makes any difference. Make sure to switch to using domain names that aren't in use by other people... [A common convention is to use .lan or .local as the top-level domain if you are using non-public domain names.] Thanks, I hadn't thought of using a non-existant top level domain. I've changed the hostname to daemon.foo.lan and now localhost.foo.lan resolves to 127.0.0.1 as it should. Unfortunately, I still get the same response form ntpq: daemon:~ % sudo ntpq -p ntpq: write to localhost.foo.lan failed: Permission denied Even with my firewall disabled I get this response. What about ntpq -pn? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3 - found the problem!
On Sat, 22 Jan 2005 02:32, Lowell Gilbert wrote: Ian Moore [EMAIL PROTECTED] writes: On Wed, 19 Jan 2005 00:54, Lowell Gilbert wrote: Ian Moore [EMAIL PROTECTED] writes: I've just realised I'm not running a name server at all on my 5.3 system. I have 4.9 installed on this computer too I'd set up the caching server on it, I guess I forgot that step when I installed 5.3. I'll set it up see that makes any difference. Make sure to switch to using domain names that aren't in use by other people... [A common convention is to use .lan or .local as the top-level domain if you are using non-public domain names.] Thanks, I hadn't thought of using a non-existant top level domain. I've changed the hostname to daemon.foo.lan and now localhost.foo.lan resolves to 127.0.0.1 as it should. Unfortunately, I still get the same response form ntpq: daemon:~ % sudo ntpq -p ntpq: write to localhost.foo.lan failed: Permission denied Even with my firewall disabled I get this response. What about ntpq -pn? No, I get the same response from that too. Cheers, -- Ian GPG Key: http://homepages.picknowl.com.au/imoore/imoore.asc pgpjGfhWMjOdi.pgp Description: PGP signature
Re: ntpd problems since upgrading to 5.3
On Tue, Jan 18, 2005 at 07:26:16AM +0100, Christian Hiris wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 01:09, John wrote: 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 I can reproduce this, it only happens if you try start more than one ntp-daemons on the same interfaces. Better start this via rc. # killall ntpd # /etc/rc.d/ntpd start Starting ntpd. # /etc/rc.d/ntpd start ntpd already running? (pid=68961). # /etc/rc.d/ntpd stop Stopping ntpd. Thank you, Christian, but I have confirmed that ntp is not running before the attempt that generates that message. # ps ax | grep ntp # killall ntpd No matching processes were found # ntpdc -c peers ntpdc: read: Connection refused So, I think we can be pretty sure at this point that ntpd is NOT running. Then.. I can't use the script to start ntp, because the config parameters are to not start it, so # ntpd Boom! I immediately get the error message that I gave above! If it were already running, I could understand, but my point is that I've been pretty thorough in determining that it is my first attempt to run it that gets this error message. I have also tried running ntpdate before starting ntpd, or not doing it. If I do it, it works correctly, indicating that ntpd is not running, becuase ntpdate will fail if ntpd is running. I have also NOT run ntpdate first (after a reboot) just to prove to myself that there's nothing residual it could leave that would make ntpd complain about this. It's very puzzling! -- John Lind [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3 - found the problem!
Ian Moore [EMAIL PROTECTED] writes: I've just realised I'm not running a name server at all on my 5.3 system. I have 4.9 installed on this computer too I'd set up the caching server on it, I guess I forgot that step when I installed 5.3. I'll set it up see that makes any difference. Make sure to switch to using domain names that aren't in use by other people... [A common convention is to use .lan or .local as the top-level domain if you are using non-public domain names.] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3
On Tue, Jan 18, 2005 at 07:23:41AM -0600, John wrote: On Tue, Jan 18, 2005 at 07:26:16AM +0100, Christian Hiris wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 01:09, John wrote: 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 I can reproduce this, it only happens if you try start more than one ntp-daemons on the same interfaces. Better start this via rc. # killall ntpd # /etc/rc.d/ntpd start Starting ntpd. # /etc/rc.d/ntpd start ntpd already running? (pid=68961). # /etc/rc.d/ntpd stop Stopping ntpd. Thank you, Christian, but I have confirmed that ntp is not running before the attempt that generates that message. # ps ax | grep ntp # killall ntpd No matching processes were found # ntpdc -c peers ntpdc: read: Connection refused So, I think we can be pretty sure at this point that ntpd is NOT running. Then.. I can't use the script to start ntp, because the config parameters are to not start it, so # ntpd Boom! I immediately get the error message that I gave above! If it were already running, I could understand, but my point is that I've been pretty thorough in determining that it is my first attempt to run it that gets this error message. I have also tried running ntpdate before starting ntpd, or not doing it. If I do it, it works correctly, indicating that ntpd is not running, becuase ntpdate will fail if ntpd is running. I have also NOT run ntpdate first (after a reboot) just to prove to myself that there's nothing residual it could leave that would make ntpd complain about this. It's very puzzling! OK. Get this. I just generated a custom kernel to get rid of all the good stuff that this laptop will never support. It just so happens to be a couple of days later (in CVS terms) than the one I was running. I decided to take a chance and just do the installkernel rather than install the whole world. Now ntpd works. I didn't change any config files, DNS, or anything else - just installed my custom kernel. I still get an error message, but now it simply says no IPv6 interfaces found and runs successfully. Go figure. My best guess is that my prior cvsup of 5-STABLE had something in the kernel environment and ntpd slightly out of sync, with ntpd being ahead of the kernel, and now, even though I didn't do an installworld, that skew was resolved. While rare, it is the possibility of this skew that makes me uncomfortable with cvsup - but having no better plans, I'll keep using it! I may have to figure out how to maintain a local release tree that is behind the -STABLE tree, or something. I truly do not know what the right answer is. -- John Lind [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3
On Tue, Jan 18, 2005 at 04:04:30PM -0600, John wrote: On Tue, Jan 18, 2005 at 07:23:41AM -0600, John wrote: On Tue, Jan 18, 2005 at 07:26:16AM +0100, Christian Hiris wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 01:09, John wrote: 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 I can reproduce this, it only happens if you try start more than one ntp-daemons on the same interfaces. Better start this via rc. # killall ntpd # /etc/rc.d/ntpd start Starting ntpd. # /etc/rc.d/ntpd start ntpd already running? (pid=68961). # /etc/rc.d/ntpd stop Stopping ntpd. Thank you, Christian, but I have confirmed that ntp is not running before the attempt that generates that message. # ps ax | grep ntp # killall ntpd No matching processes were found # ntpdc -c peers ntpdc: read: Connection refused So, I think we can be pretty sure at this point that ntpd is NOT running. Then.. I can't use the script to start ntp, because the config parameters are to not start it, so # ntpd Boom! I immediately get the error message that I gave above! If it were already running, I could understand, but my point is that I've been pretty thorough in determining that it is my first attempt to run it that gets this error message. I have also tried running ntpdate before starting ntpd, or not doing it. If I do it, it works correctly, indicating that ntpd is not running, becuase ntpdate will fail if ntpd is running. I have also NOT run ntpdate first (after a reboot) just to prove to myself that there's nothing residual it could leave that would make ntpd complain about this. It's very puzzling! OK. Get this. I just generated a custom kernel to get rid of all the good stuff that this laptop will never support. It just so happens to be a couple of days later (in CVS terms) than the one I was running. I decided to take a chance and just do the installkernel rather than install the whole world. Now ntpd works. I didn't change any config files, DNS, or anything else - just installed my custom kernel. I still get an error message, but now it simply says no IPv6 interfaces found and runs successfully. Go figure. My best guess is that my prior cvsup of 5-STABLE had something in the kernel environment and ntpd slightly out of sync, with ntpd being ahead of the kernel, and now, even though I didn't do an installworld, that skew was resolved. While rare, it is the possibility of this skew that makes me uncomfortable with cvsup - but having no better plans, I'll keep using it! I may have to figure out how to maintain a local release tree that is behind the -STABLE tree, or something. I truly do not know what the right answer is. Wow! Now my mind is REALLY blown! Look at the following consecutive runs of ntpdc just a few minutes part, with nothing else going on in between: pearl# !! ntpdc -c peers remote local st poll reach delay offsetdisp === =dexter.starfire 192.168.1.53 3 256 17 0.00026 0.023755 0.93869 =dauntless.starf 192.168.1.53 4 256 17 0.00053 0.016804 0.93942 pearl# pwd /home/john pearl# !nt ntpdc -c peers remote local st poll reach delay offsetdisp === =dexter.starfire 192.168.1.53 3 641 0.00026 0.035822 7.93750 =dauntless.starf 192.168.1.53 4 641 0.00061 0.035934 7.93750 pearl# ps ax | grep ntp 751 ?? Ss 0:00.05 ntpd pearl# That last line is me confirming that it's still the same PID for ntpd. What happened here? The reachability mask went from 17 to 1, the dispersion popped WAY up, the offset increased, and the polling time went down. Maybe this is normal for ntpd in some set of circumstance, but I've not seen it before. The other odd thing, and I haven't shown you enough runs to demonstrate it, is that the offset was INCREASING prior to this apparent reset. Maybe it failed to converge and started over? But the polling interval kept increasing... Anybody know what just happened? -- John Lind [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 23:14, John wrote: On Tue, Jan 18, 2005 at 04:04:30PM -0600, John wrote: On Tue, Jan 18, 2005 at 07:23:41AM -0600, John wrote: On Tue, Jan 18, 2005 at 07:26:16AM +0100, Christian Hiris wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 01:09, John wrote: 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 I can reproduce this, it only happens if you try start more than one ntp-daemons on the same interfaces. Better start this via rc. # killall ntpd # /etc/rc.d/ntpd start Starting ntpd. # /etc/rc.d/ntpd start ntpd already running? (pid=68961). # /etc/rc.d/ntpd stop Stopping ntpd. Thank you, Christian, but I have confirmed that ntp is not running before the attempt that generates that message. # ps ax | grep ntp # killall ntpd No matching processes were found # ntpdc -c peers ntpdc: read: Connection refused So, I think we can be pretty sure at this point that ntpd is NOT running. Then.. I can't use the script to start ntp, because the config parameters are to not start it, so # ntpd Boom! I immediately get the error message that I gave above! If it were already running, I could understand, but my point is that I've been pretty thorough in determining that it is my first attempt to run it that gets this error message. I have also tried running ntpdate before starting ntpd, or not doing it. If I do it, it works correctly, indicating that ntpd is not running, becuase ntpdate will fail if ntpd is running. I have also NOT run ntpdate first (after a reboot) just to prove to myself that there's nothing residual it could leave that would make ntpd complain about this. It's very puzzling! OK. Get this. I just generated a custom kernel to get rid of all the good stuff that this laptop will never support. It just so happens to be a couple of days later (in CVS terms) than the one I was running. I decided to take a chance and just do the installkernel rather than install the whole world. Now ntpd works. I didn't change any config files, DNS, or anything else - just installed my custom kernel. I still get an error message, but now it simply says no IPv6 interfaces found and runs successfully. Go figure. My best guess is that my prior cvsup of 5-STABLE had something in the kernel environment and ntpd slightly out of sync, with ntpd being ahead of the kernel, and now, even though I didn't do an installworld, that skew was resolved. While rare, it is the possibility of this skew that makes me uncomfortable with cvsup - but having no better plans, I'll keep using it! I may have to figure out how to maintain a local release tree that is behind the -STABLE tree, or something. I truly do not know what the right answer is. Wow! Now my mind is REALLY blown! Look at the following consecutive runs of ntpdc just a few minutes part, with nothing else going on in between: pearl# !! ntpdc -c peers remote local st poll reach delay offsetdisp === =dexter.starfire 192.168.1.53 3 256 17 0.00026 0.023755 0.93869 =dauntless.starf 192.168.1.53 4 256 17 0.00053 0.016804 0.93942 pearl# pwd /home/john pearl# !nt ntpdc -c peers remote local st poll reach delay offsetdisp === =dexter.starfire 192.168.1.53 3 641 0.00026 0.035822 7.93750 =dauntless.starf 192.168.1.53 4 641 0.00061 0.035934 7.93750 pearl# ps ax | grep ntp 751 ?? Ss 0:00.05 ntpd pearl# That last line is me confirming that it's still the same PID for ntpd. What happened here? The reachability mask went from 17 to 1, the dispersion popped WAY up, the offset increased, and the polling time went down. Maybe this is normal for ntpd in some set of circumstance, but I've not seen it before. The other odd thing, and I haven't shown you enough runs to demonstrate it, is that the offset was INCREASING prior to this apparent reset. Maybe it failed to converge and started over? But the polling interval kept increasing... Anybody know what just happened? To me, this behaviour seems to be normal. http://www.eecis.udel.edu/~mills/database/papers/trans.pdf http://www.eecis.udel.edu/~mills/database/papers/allan.pdf Cheers, ch - -- Christian Hiris [EMAIL PROTECTED] | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu -BEGIN PGP SIGNATURE- Version:
Re: ntpd problems since upgrading to 5.3
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 offsetdisp === *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 offsetdisp === =dexter.starfire 192.168.1.5316 640 0.0 0.00 0.0 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). -- John Lind [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3
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 offsetdisp === *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 offsetdisp === =dexter.starfire 192.168.1.5316 640 0.0 0.00 0.0 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! -- John Lind [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3
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 offsetdisp === *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 offsetdisp === =dexter.starfire 192.168.1.5316 640 0.0 0.00 0.0 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 [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 01:09, John wrote: 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 Try to add disable auth to your ntp.conf. 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 offsetdisp === *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 offsetdisp === =dexter.starfire 192.168.1.5316 640 0.0 0.00 0.0 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? Hi, I also had some problems with ntpd, when I
Re: ntpd problems since upgrading to 5.3
Christian Hiris wrote: On the server ntp.matrix.net I run ntpd with the following config files (This machine still runs 5.3-BETA-4): # cat /etc/rc.conf | grep ntp ntpdate_flags=-b clock.netcetera.dk tick.keso.fi ntpdate_enable=YES ntpd_enable=YES - - No need for ntpdate -b. Following has same effect, using the time servers from ntp.conf: xntpd_enable=YES xntpd_flags=-g At least, that's how I use it. Rob. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 05:23, Rob wrote: Christian Hiris wrote: On the server ntp.matrix.net I run ntpd with the following config files (This machine still runs 5.3-BETA-4): # cat /etc/rc.conf | grep ntp ntpdate_flags=-b clock.netcetera.dk tick.keso.fi ntpdate_enable=YES ntpd_enable=YES - - No need for ntpdate -b. Following has same effect, using the time servers from ntp.conf: xntpd_enable=YES xntpd_flags=-g Thanks, I know this, but old the old ntpdate method has been reported to be faster. The use of xntpd* variables has been deprecated some time ago. http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.subr.diff?r1=1.3r2=1.4f=h Cheers, ch - -- Christian Hiris [EMAIL PROTECTED] | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB7JbR09WjGjvKU74RAj8aAJwPs+9rIFGrwKfYipDbZvvu/jYqFQCfeJD0 GcE2vzHpGCeLTkFfSdxi4lw= =lDYr -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3 - found the problem!
On Tue, 18 Jan 2005 12:50, Christian Hiris wrote: On Tuesday 18 January 2005 01:09, John wrote: 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 Try to add disable auth to your ntp.conf. I tried that, sadly it made no difference. However, I think I've found the problem - the error message I get with ntpq is write to localhost.foo.com failed: Permission denied. My machine's hostname is daemon.foo.com, something I assumed was safe to use. Well it turns out that localhost.foo.com actually exists, it resolves to 216.234.246.150, as do lots of others like localhost.foo.org, foobar.org, example.org etc. So ntpq must do a reverse name lookup for localhost.whatever the host's domain name is and in my case it doesn't reslove to 127.0.0.1 but to 216.234.246.150, to which ntpq has no access - hence the Permission denied error! Now I'm not sure what the best way to get around this would be. I run a caching name server on the machine, so I guess I can tweak it to force localhost.foo.com resolve to 127.0.0.1 Cheers, -- Ian GPG Key: http://homepages.picknowl.com.au/imoore/imoore.asc pgpNlb5tuOeDC.pgp Description: PGP signature
Re: ntpd problems since upgrading to 5.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 01:09, John wrote: 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 I can reproduce this, it only happens if you try start more than one ntp-daemons on the same interfaces. Better start this via rc. # killall ntpd # /etc/rc.d/ntpd start Starting ntpd. # /etc/rc.d/ntpd start ntpd already running? (pid=68961). # /etc/rc.d/ntpd stop Stopping ntpd. - -- Christian Hiris [EMAIL PROTECTED] | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB7KwI09WjGjvKU74RAiOsAJwM4urvuaeSka6k22X2AnSwh/ty0QCggDLA +aT+p15ZiIqVdK8HkvMdFV0= =yI9F -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3 - found the problem!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 18 January 2005 07:19, Ian Moore wrote: Now I'm not sure what the best way to get around this would be. I run a caching name server on the machine, so I guess I can tweak it to force localhost.foo.com resolve to 127.0.0.1 I'm running ntpd and a caching nameserver on one machine, too. The external IP is only referenced by /etc/hosts. My bind holds only the internal networks, including it's own localhost. There also could be some influence from your /etc/resolv.conf, but I'm not sure about. # dig localhost.matrix.net ; DiG 9.3.0 localhost.matrix.net ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47348 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;localhost.matrix.net. IN A ;; ANSWER SECTION: localhost.matrix.net. 3600IN A 127.0.0.1 ;; AUTHORITY SECTION: matrix.net. 3600IN NS ns.matrix.net. ;; ADDITIONAL SECTION: ns.matrix.net. 3600IN A 192.168.123.1 ;; Query time: 1 msec ;; SERVER: 192.168.123.1#53(192.168.123.1) ;; WHEN: Tue Jan 18 07:27:54 2005 ;; MSG SIZE rcvd: 87 # cat /etc/resolv.conf search matrix.net nameserver 127.0.0.1 - -- Christian Hiris [EMAIL PROTECTED] | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB7LAC09WjGjvKU74RAkZjAKCC6C+33mjGMf3tK36/36KV0yUrlgCdGpr8 6RVG2fKYma3/+tJbdPrx3YI= =pwmk -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd problems since upgrading to 5.3 - found the problem!
On Tue, 18 Jan 2005 17:13, Christian Hiris wrote: On Tuesday 18 January 2005 07:19, Ian Moore wrote: Now I'm not sure what the best way to get around this would be. I run a caching name server on the machine, so I guess I can tweak it to force localhost.foo.com resolve to 127.0.0.1 I'm running ntpd and a caching nameserver on one machine, too. The external IP is only referenced by /etc/hosts. My bind holds only the internal networks, including it's own localhost. There also could be some influence from your /etc/resolv.conf, but I'm not sure about. # dig localhost.matrix.net ; DiG 9.3.0 localhost.matrix.net ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47348 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;localhost.matrix.net. IN A ;; ANSWER SECTION: localhost.matrix.net. 3600IN A 127.0.0.1 ;; AUTHORITY SECTION: matrix.net. 3600IN NS ns.matrix.net. ;; ADDITIONAL SECTION: ns.matrix.net. 3600IN A 192.168.123.1 ;; Query time: 1 msec ;; SERVER: 192.168.123.1#53(192.168.123.1) ;; WHEN: Tue Jan 18 07:27:54 2005 ;; MSG SIZE rcvd: 87 # cat /etc/resolv.conf search matrix.net nameserver 127.0.0.1 Oops, I've just realised I'm not running a name server at all on my 5.3 system. I have 4.9 installed on this computer too I'd set up the caching server on it, I guess I forgot that step when I installed 5.3. I'll set it up see that makes any difference. Cheers, -- Ian GPG Key: http://homepages.picknowl.com.au/imoore/imoore.asc pgpSR9uAmIFYt.pgp Description: PGP signature
ntpd problems since upgrading to 5.3
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 can run ntpq without any flags (and get the ntpq prompt), but as soon as I try to run commands in it like associations or peers, it just comes back with that same error message. I assume this has something to do with the first error message that ntpq is trying ( failing) to bind to ipv6, but I'm unsure why that's the case. Here's the output of ifconfig in case that helps: vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.1.5 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::204:61ff:fe46:be89%vr0 prefixlen 64 scopeid 0x1 ether 00:04:61:46:be:89 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 I've tried disabling my firewall and running ntpq -p again, but I still get the same response. I've tried googling for a solution, but haven't found anything as yet so I hope someone here can help! 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 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 Cheers, -- Ian GPG Key: http://homepages.picknowl.com.au/imoore/imoore.asc pgp6RektuyCqN.pgp Description: PGP signature
Re: ntpd problems since upgrading to 5.3
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 Does that help you? Rob. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
