Hide Forgot
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.
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
NEEDINFO_PM has been deprecated. Changing status to NEEDINFO and changing ownership to pm manager.
Does need info mean I haven't provided enough info? If so, I'll be happy to expound upon what have already provided.
What do you mean when you say "NIS is gobbling them all up". Are they all in ESTABLISHED state or in TIMEWAIT
Most of them appear to be in TIME_WAIT. There are a few in ESTABLISHED.
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?
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.
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.