Bug 171936

Summary:	Once started ypbind occupies more and more tcp ports
Product:	[Fedora] Fedora	Reporter:	Daniel Levine <daniel.levine>
Component:	ypbind	Assignee:	Daniel Riek <riek>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Ben Levenson <benl>
Severity:	high	Docs Contact:
Priority:	medium
Version:	4	CC:	cfeist, steved
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:	2008-03-09 21:46: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 Daniel Levine 2005-10-27 22:08:32 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Description of problem:
Starting up ypbind using startup script using broadcast detection of ypserver, NIS resolves the server and everything NIS oriented works fine.

However, if one looks at the tcp ports allocated between the NIS client and server (on the client side) with netstat -p, it appears that NIS is gobbling them all up.  Other applications (in my case Arkeia) then have difficulty  finding a free port.  I'm not sure, but the number of ports might grow very large (we're talking about over 200 ports) and then shrink down to 0 and start growing again.

Stopping the service appears to stop the growing and eventually frees up the ports.

Version-Release number of selected component (if applicable):
ypbind-1.17.2-5 (FC4) and ypbind-1.17.2-1 (FC2)

How reproducible:
Always

Steps to Reproduce:
0. netstat -p | grep myNisServerName | wc -l # results in 0
1. /sbin/service ypbind start
2. netstat -p | grep myNisServerName | wc -l
3. repeat 2 to watch results grow
  

Actual Results:  The number printed grows larger and larger as ypbind occupies the tcp ports.

Expected Results:  It should take a few ports and stay that way instead of hogging up the tcp ports and preventing other applications from getting a port when it needs one.

Additional info:

This isn't a memory leak, but I suppose it's a severe resource leak preventing other apps from working properly.

Comment 1 Daniel Levine 2005-11-11 14:34:41 UTC

Hi,

I submitted this a while back.  Nothing has happened on this bug report.  Is 
my report or understanding of ypbind deficient?  I have a system I really need 
to run ypbind on that can't run it or it interferes with another program that 
needs a few ports during network backup.

Thanks,

Dan

Comment 2 David Lawrence 2006-03-10 17:24:17 UTC

NEEDINFO_PM has been deprecated. Changing status to NEEDINFO and changing
ownership to pm manager.

Comment 3 Daniel Levine 2006-03-10 18:14:52 UTC

Does need info mean I haven't provided enough info?  If so, I'll be happy to 
expound upon what have already provided.

Comment 4 Steve Dickson 2006-07-25 15:32:27 UTC

What do you mean when you say "NIS is gobbling them all up". 
Are they all in ESTABLISHED state or in TIMEWAIT

Comment 5 Daniel Levine 2006-07-25 20:40:52 UTC

Most of them appear to be in TIME_WAIT.  There are a few in ESTABLISHED.

Comment 8 Daniel Levine 2006-08-08 15:35:01 UTC

So what does that mean?  Or does that mean I'm an idiot? :-)

The reason I'm asking was the Arkeia people thought that ypbind was occupying 
the ports and causing it to have difficulty making its own connections.

Is this normal behavior for ypbind clients once they are  bound to a yp 
server?  Or is there something interesting going on in my configuration?

Comment 9 Christian Iseli 2007-01-22 10:15:09 UTC

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 10 petrosyan 2008-03-09 21:46:03 UTC

Fedora Core 4 is no longer maintained.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.