ypbind-1.19-1 Make /etc/yp.conf point to a working NIS server: domain example.com server test.machine.redhat.com And run: while true; do ypcat hosts > /dev/null ; echo -n ".";done After a period of time, ypbind will be leaking a lot of file descriptors. $ netstat -unap | grep ypbind | wc -l 68 ypbind will be leaking more sockets if the yp.conf contains unreachable servers. The same problem occurs on RHEL3.
Client requests that we bump the priority as they're having problems due to the issue: <snip> Bumping this priority. piidb243 /var/log 22# lsof -n -p 12354|grep UDP|wc -l 424 </snip>
It appears there is some type of race condition in ypbind's server pinging code that is causing this port leak. The ports that are bing leaked are actually listening ports, meaning they are ports that are waiting for incoming traffic. Using the '-no-ping' flag to ypbind, at least in my testing, does stop the port from being leaked (which does make sense since setting that flag turns off the code in question). Also in my testing, it appears setting that flag has no ill effects on ypbind recovering from a server outage. The recover is a bit verbose (in the amount of traffic that is generated) but ypbind does seem to recover. So I would suggest (for now) setting the '-no-ping' flag as a work-around, until we get to the bottom of the root cause of this leakage...
Created attachment 142519 [details] Purposed Patch There as a race condition created between the pinging thread and main ypbind thread. This condition can causes both threads to ping a server (in this case a dead one) at the same time. This in turn causes listening ports to be created that will never be closed. In my testing, this patch seem to fix the problem by having the thread check the state of the connect to the server once it gets the mutex. If the connection has has already been made, depending which thread it is, the appropriate action will be taken.
Fixed in ypbind-1.17.2-11
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Do we need to clone this for RHEL 5?
> Do we need to clone this for RHEL 5? there is on already bz217874
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0263.html
I've opened the request against RHEL3 as IT 125349 and we'll follow it there. Internal Status set to 'Resolved' Status set to: Closed by Tech Ticket type set to: 'Problem' This event sent from IssueTracker by fhirtz issue 99997