From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Description of problem: From time to time we've seen cron jobs get timeouts connecting to services on localhost. Finally caught it in the act, tried to telnet to port 25 on localhost, and it attempted to connect to some third-party IP address instead of 127.0.0.1! > telnet localhost 25 Trying 203.210.151.30... telnet: connect to address 203.210.151.30: Connection refused > ping localhost PING localhost (203.210.151.30) from 204.212.42.4 : 56(84) bytes of data. 64 bytes from localhost (203.210.151.30): icmp_seq=1 ttl=50 time=532 ms 64 bytes from localhost (203.210.151.30): icmp_seq=2 ttl=50 time=538 ms Further investigation showed that that IP address had recently sent us email, triggering a reverse DNS lookup in sendmail. Reverse DNS pointed to localhost. Restarting nscd solved the problem. Spotted the same thing with another IP (again rDNS triggered through sendmail), disabled nscd entirely, and we haven't seen it since. Version-Release number of selected component (if applicable): nscd-2.2.5-44.legacy.3 How reproducible: Sometimes Steps to Reproduce: We were unable to induce the cache poisoning deliberately, but we were able to observe it several times, always under the same circumstances (following incoming mail from an IP with rDNS pointing to localhost). Actual Results: Attempting to ping or telnet to localhost tried to connect to the wrong IP address. Expected Results: Localhost should have resolved to 127.0.0.1 as set in /etc/hosts Additional info: This may be related to bug 152761 about a problem with the resolver library in glibc. However, we were already running the glibc release that is supposed to have fixed that bug.
What do your /etc/hosts and /etc/nswitch.conf files contain?
Relevant lines from... /etc/hosts: 127.0.0.1 localhost.localdomain localhost localhost.speed.net - I have since changed this to: 127.0.0.1 localhost localhost.localdomain /etc/nsswitch.conf: hosts: files dns
Seems to be a known issue fixed in later versions of glibc...I'll try and find a patch... See bug 90463 and bug 56545
Looks like the glibc-2.2.4-nscd-hstcache.patch patch from glibc-2.2.4-32.18.src.rpm takes care of this issue. I'll build some test packages for rhl7.3 tomorrow.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are updated glibc packages to test/QA that may correct the issue: * Wed Apr 27 2005 Marc Deslauriers <marcdeslauriers> 2.2.4-44.legacy.4 - - Added patch so gethostbyaddr and gethostbyname don't use the same cache 2ed45236c3f1dc1ad090ca068b6ab9871ec7a0c2 glibc-2.2.5-44.legacy.4.i386.rpm d342ed96344b248e44a69fffab8ecfec7c5af3d1 glibc-2.2.5-44.legacy.4.i686.rpm caa130a388f5844de8d0f765c1af01afabb71ad3 glibc-2.2.5-44.legacy.4.src.rpm cdfa401bf9415547c5945ef1751a614856144e18 glibc-common-2.2.5-44.legacy.4.i386.rpm 7fea39b6b95b359dd876782a7a372577492942a1 glibc-debug-2.2.5-44.legacy.4.i386.rpm e47473b12c68fa09a7a100ffc5eb9f395c22e52f glibc-debug-2.2.5-44.legacy.4.i686.rpm f8cd5b999a8373a509a23adb71618dcf4c475d6e glibc-debug-static-2.2.5-44.legacy.4.i386.rpm 2fd3461497d86cb8d7abf3c135e42a255da027fa glibc-devel-2.2.5-44.legacy.4.i386.rpm 864c634b5adac25f5bab5d3ccf1d2923c4a19fbf glibc-profile-2.2.5-44.legacy.4.i386.rpm cb2221cb4c71a399dda76b9fe7338e6a6bfc8dfb glibc-utils-2.2.5-44.legacy.4.i386.rpm 46049abdeda819e1682d4deeda69f655a2131525 nscd-2.2.5-44.legacy.4.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-2.2.5-44.legacy.4.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-2.2.5-44.legacy.4.i686.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-2.2.5-44.legacy.4.src.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-common-2.2.5-44.legacy.4.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-debug-2.2.5-44.legacy.4.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-debug-2.2.5-44.legacy.4.i686.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-debug-static-2.2.5-44.legacy.4.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-devel-2.2.5-44.legacy.4.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-profile-2.2.5-44.legacy.4.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-utils-2.2.5-44.legacy.4.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/nscd-2.2.5-44.legacy.4.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCb82nLMAs/0C4zNoRAlt3AJ4uiL0F+m+RiIQWWHWRLZI+gpdNJQCeN4M6 skHXs07HwX6DfTiBgGwMrEI= =LpSt -----END PGP SIGNATURE-----
I'll mark this one duplicate of #152848 so that we only need to track the glibc update in one place.. (I wonder if there's a better way to do these..)
*** This bug has been marked as a duplicate of 152848 ***