Bug 171936 - Once started ypbind occupies more and more tcp ports
Summary: Once started ypbind occupies more and more tcp ports
Alias: None
Product: Fedora
Classification: Fedora
Component: ypbind   
(Show other bugs)
Version: 4
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Daniel Riek
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-27 22:08 UTC by Daniel Levine
Modified: 2008-03-09 21:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-09 21:46:03 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 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:

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

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.



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 ?


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.

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