Bug 23712 - udp sockets remain after dns reverse lookup fails
Summary: udp sockets remain after dns reverse lookup fails
Status: CLOSED DUPLICATE of bug 18332
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-10 15:36 UTC by dro
Modified: 2016-11-24 15:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-11 12:34:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description dro 2001-01-10 15:36:22 UTC
I have two RedHat 7.0 boxes running with the 2.2.16 SMP kernel.

 Some services on both machines appear to have sockets remaining open to 
the primary and secondary dns servers after a reverse lookup fails.

 The first indication of the problem was when my max file descriptor limit 
was reached, because of this I had increased the limit. After a bit more 
investigation I noticed that when a reverse dns request is made by certain 
services (ie: apache, sendmail, xinetd) and the remote authoritative host 
for the reverse ip block fails, a socket is left resident in the system to 
the local primary or secondary dns servers.

 If the system is left unchecked, the entire machine will lockup after 
roughly two days of activity on a medium load server.

 The sockets are closed after the afflicted service is stopped and 

 I have only been able to reproduce these events on two SMP servers which 
run the same hardware configurations in each. I don't have access to a 
third server which runs RedHat 7 with SMP and different hardware to 
completely verify the circumstances.

 I have only seen one other instance of this happening in the newsgroups 
and email lists. The other company affected had contacted me inregards to 
the problem. After they had downgraded to RedHat 6.2, the problem was 

Linux web 2.2.16-22smp #3 SMP Fri Nov 3 22:08:03 EST 2000 i686 unknown
apache compiled with egcs-2.91.66

Visual of the problem:

# netstat -an | grep '.53' | grep udp
udp        0      0 web:3129        ESTABLISHED
udp        0      0 web:3128        ESTABLISHED
udp        0      0 web:3127        ESTABLISHED
udp        0      0 web:3126        ESTABLISHED
udp        0      0 web:3125        ESTABLISHED
udp        0      0 web:3124        ESTABLISHED

# fuser -n udp 3124
3124/udp:             2360

# ps ax | grep 2360
 2360 ?        S      0:00 /usr/local/httpd/bin/httpd

# netstat -an | grep '.53' | grep udp | wc -l

Packet level visual:

14:03:40.085211 eth0 > web.efni.com.2640 > rhymes.efni.com.domain: 31440+ 
PTR? (44)
14:03:40.086942 eth0 < rhymes.efni.com.domain > web.efni.com.2640: 31440 
ServFail 0/0/0 (44) (DF)
udp        0      0        

15:11:07.482324 eth0 > web.efni.com.2168 > rhymes.efni.com.domain: 54530+ 
PTR? (44)
15:11:07.484169 eth0 < rhymes.efni.com.domain > web.efni.com.2168: 54530 
ServFail 0/0/0 (44) (DF)
udp        0      0        

 In the two instances listed above, I had waited roughly two minutes 
before checking for the socket in a netstat.

 This bug is marked as glibc as I believe it was the proper place for the 
report, but I could very easily have been mistaken on this..


Joshua Hirsh
UNIX Systems Administration
Tel: (705) 474-3364 ext. 2557
Fax: (705) 472-9202
PGP KEY: http://users.efni.com/admin/pgp/

Comment 1 Tomas Mraz 2001-01-11 10:29:06 UTC
I have the same problem which is on my machine triggered by silent releasing of
the eth0 interface (which I still don't know why it releases). After that the
open UDP sockets (by httpd especially) stay opened even when I start the eth0
interface again.
I have RedHat Linux 7.0 with all recent updates applied but with kernel 2.2.18.
Machine is Celeron II 566 with ASUS CUV4X MB and 3COM ethernet card.

Comment 2 Jakub Jelinek 2001-01-11 12:47:17 UTC

*** This bug has been marked as a duplicate of 18332 ***

Note You need to log in before you can comment on or make changes to this bug.