Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 76610

Summary:	xinetd 2.3.9-0.72 leaves sockets hanging in CLOSE_WAIT status
Product:	[Retired] Red Hat Linux	Reporter:	Elson, Del <del>
Component:	xinetd	Assignee:	Trond Eivind Glomsrxd <teg>
Status:	CLOSED DUPLICATE	QA Contact:	Brock Organ <borgan>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.2	CC:	herrold
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-10-25 03:06:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Elson, Del 2002-10-24 03:16:24 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
xinetd 2.3.9-0.72 leaves sockets hanging in a CLOSE_WAIT status when connections
are opened and then closed to an internal service (such as time or daytime).


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.enable the "daytime" service (eg: using ntsysv)
2.telnet localhost daytime
3.The date and time will be displayed, but the socket is never closed.
4.Close the socket manually using ^] quit
5.netstat -a | grep CLOSE_WAIT

	

Actual Results:  The hanging socket will be displayed.

The machine eventually fails to open any further connections, and the "too many
open files" error is displayed in the log.


Expected Results:  The socket should have been closed by the xinetd server.


Additional info:

This happened to an older version of inetd but was fixed, it has now recurred in
the latest release of xinetd.

For example, see bugs # 14876, 11548, 12779, 13636, 16729, 21740, 44722, etc.

Comment 1 R P Herrold 2002-10-25 03:05:56 UTC

I am receiving this with the tftp service under high load (40 simultaneous
connections at the start of the day when PXE booting is starting up), and this
version -- I had to revert to the prior version to re-establish service

Comment 2 Milan Kerslager 2002-10-25 07:47:43 UTC

I see the same problem on RH 7.3: xinetd-2.3.9-0.73
Marked as duplicate of #76146 which have kernel-patch included too.

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