Red Hat Bugzilla – Bug 204465
ypbind leaks UDP ports
Last modified: 2007-11-30 17:07:27 EST
Make /etc/yp.conf point to a working NIS server:
domain example.com server test.machine.redhat.com
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
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
Bumping this priority.
piidb243 /var/log 22# lsof -n -p 12354|grep UDP|wc -l
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
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]
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
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.
I've opened the request against RHEL3 as IT 125349 and we'll follow it
Internal Status set to 'Resolved'
Status set to: Closed by Tech
Ticket type set to: 'Problem'
This event sent from IssueTracker by fhirtz