[EMAIL PROTECTED] (Luc Pardon) writes: > Well, I'm about to give up. > > My logs are getting flooded with "Connection refused" messages and I can't > find why, much less how to stop them. > > This is a rather oldish RH Linux box with two network cards. One is connected > to the bad world outside via an ADSL router, the other to the internal > network (192.168.x.x). It gets its time from stratum 2 servers and provides > time to the internal network. > > I've been running ntp on that box since 2001. In June 2005, I upgraded to ntp > 4.2.0. > > Life was beautiful for more than a year until, last week, I suddenly started > getting "Connection refused" messages in syslog. > > > Sep 3 04:06:32 gida ntpd[4796]: recvfrom(193.190.230.65) fd=9: Connection > refused > > Sep 3 04:06:32 gida ntpd[4796]: recvfrom(193.190.230.65) fd=9: > Connection refused This error message from the kernel is a bit unusual, but you said it was running on Linux...
> > This is because I checked the mailing list and decided to upgrade to 4.2.2p3. > Almost as soon as I started the new version, the "connection refused" was > back, but different now: > > > Sep 7 09:24:25 gida ntpd[26405]: ntpd [EMAIL PROTECTED] Thu Sep 7 > 07:05:22 UTC > > 2006 (1) > > Sep 7 09:24:25 gida ntpd[26406]: precision = 1.000 usec > > Sep 7 09:24:25 gida ntpd: ntpd startup succeeded > > Sep 7 09:24:26 gida ntpd[26406]: Listening on interface wildcard, > 0.0.0.0#123 Disabled > > Sep 7 09:24:26 gida ntpd[26406]: Listening on interface lo, > 127.0.0.1#123 Enabled > > Sep 7 09:24:26 gida ntpd[26406]: Listening on interface eth0, > 192.168.1.23#123 > > Enabled > > Sep 7 09:24:26 gida ntpd[26406]: Listening on interface eth1, > 192.168.254.2#123 Enabled > > Sep 7 09:24:26 gida ntpd[26406]: kernel time sync status 0040 > > Sep 7 09:24:32 gida ntpd[26406]: frequency initialized 128.381 PPM from > /etc/ntp/drift > > Sep 7 09:24:32 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection > refused > > Note that, at startup, it says "Listening on interface wildcard, > 0.0.0.0#123 Disabled" but that seems a blatant lie since lsof shows that it > does have a socket open there. > The socket being bound does not allow you to call that a lie. The Disabled information just documents that pakets received on that socket will be discarded. > The 'refused' messages come two at a time and in 64 second intervals. > So it seems to be related with some query activity. > I tried adding a line 'manycastclient 224.1.1.1' to ntp.conf. The messages > stopped and came back. So it doesn't make a difference. > > I tried removing the 'restrict' lines from ntp.conf but it doesn't make a > difference. restrict is not related to this behavior. > > I then pulled 4.2.3p39 from dev and tried again. Same thing, the only > difference is that it doesn't mention the wildcard IF at startup. > > I noticed that 193.190.230.66 is a stratum 1 server and not a 2 like the > others. Either I missed that when I added it to ntp.conf in May 2005 or they > changed from 2 to 1 since then. In any case I removed it but it doesn't make > any difference. > > I tried the debug output but it doesn't tell me anything. All I can make > of it is that there is only one 'refused' in the debug output and two in the > syslog. Also, the 'refused' comes after several seconds of silence in the > debug output. It doesn't tell me why it thinks it should call recvfrom. The socket seems to be ready for reading (select && SIGIO). when ntpd reads from it it gets the error message from the kernel. As I said getting that on a recvfrom is unusal and delivered from the kernel - ntpd just documents that. > > Needless to say, "tcpdump -i eth1 port ntp" (eth1 being fd 51) doesn't > show activity that might be related to the refusals. I suspect that icmp messages (probably port unreachable) being received. So try "tcpdump -i eth1 port ntp or icmp" and see whether such icmp messages show up and who sends them. > > One thing that I should add is that I can't ntpq locally on that machine. > It says "Name or service not known". From what I can see with strace it > seems to be looking in /etc/services from something. But I wouldn't know > what, "ntp" is definitely in there. In any case, this started happening one > year ago so it should have nothing to do with the "refused" messages (but > maybe with the ntp 4.1.x to 4.2.x transition). I can query the box remotely, > from another Linux, without problems. This looks like a local setup problem other system have following line in /etc/services: ntp 123/udp # Network Time Protocol Frank _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
