Red Hat Bugzilla – Bug 430825
RPC port selection for ypbind may collide with CUPS port on boot
Last modified: 2013-01-10 08:39:49 EST
+++ This bug was initially created as a clone of Bug #103401 +++
Description of problem:
On boot, ypbind occasionally grabs port 631/udp, blocking CUPS from binding to
the port. This is a glibc problem because ypbind is a RPC service that has its
port assigned dynamically through bindresvport().
The code in libc/sunrpc/bindrsvprt.c shows the port number is assigned purely
based on the PID of the ypbind process, something like
port = (PID % 424) + 600
The PID seems to vary slightly from reboot to reboot, but generally is in the
870s on the machine in question, resulting in ports assigned in the vicinity of
630. CUPS (actually, IPP) has ports 631/tcp and 631/udp reserved. NIS starts
first, so it wins, and since CUPS has a reserved Well Known Port, it can't
relocate and loses.
Version-Release number of selected component (if applicable):
Depends entirely on the PID handed to ypbind on boot, and the exact set of
services configured affects this.
The glibc algorithm already blacklists all reserved ports below 600, presumably
to avoid this exact problem. Consider altering the code to blacklist 5 to 8
additional ports in the 600-1023 range that are or may be in common use:
631 (IPP == CUPS)
749 (Kerberos V kadmin)
992-995 (SSL-enabled telnet, IMAP, IRC, and POP3)
The ports lost could be recovered, if desired, by allowing ports in the 590-600
range to be assigned by bindrsvprt().
*** Bug 168996 has been marked as a duplicate of this bug. ***
So, see bug 104301 for more details. A couple of potential implementations:
- Have services drop a file in /etc that describes the ports they use. Have
rpcbind not use those
- Just have rpcbind ignore any ports for where getsrvbyport() actually returns a
The first is more comprehensive, the last is simpler and avoids spinning every
package to add a file.
Oh, moving to rpcbind; that's more appropriate.
the latter solution of just grabbing ports that don't return names looks like
the cleanest imho.
I thinking this is more of a ypbind issue than a portmapper
issues because ypbind is the application that does the actuall
bind() call not rpcbind/portmapper.
This is a generic issue with anything that uses bindresvport(); as the solution
is not palatable in libc, rpcbind seems the quickest way to get all the users.
The only problem is by the time rpcbind see the port, the rpc
service (i.e. like ypbind) has already done the bindresvport().
Unfortunately, there is no protocol supported way for rpcbind
to fail the service registration, telling the service to go
back and rebind.
Do we have a solution for this? Fedora 9 is coming up fast, I'd have to have a
"randomly fails" type bug in our release.
No, we haven't. I'm under pressure now, I'll be glad if someone could help.
Otherwise I'll look at it when things get better.
Has portreserve been ruled out?
See https://bugzilla.redhat.com/show_bug.cgi?id=103401#c5 for when portreserve
was first mentioned (2003!).
I don't like solutions that involve modifying every package if it can be avoided...
is this really a F9 blocker if it's been like this for years? I'm reviewing the
Even if it were, we probably couldn't make substantial changes like this for F9.
I'm moving this to F10, if you've got issues with this notting feel free to
move it back, but I think that it's the right thing to do.
The fact that it's been broken for so long doesn't make it right to leave it
broken. This bug means that servers cannot be relied upon to start all their
services on boot.
I believe on OSX launchd will do something similar to portreserve for any
services it starts. Further, it looks like if the service ever dies launchd will
regrab the port until the service is restarted through it.
We've worked around this by telling each rpc service to use a specific port (via
--port options). This may be a quick way of fixing it (at least until it is
fixed properly). Would it be a bad idea to predefine a port for each of the rpc
services which didn't clash?
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
And now we've missed the F10 feature/beta freeze. Given that we don't have a current "problem", give our work around, I don't think we'd block F10 for this. I'll move it to the F10Target through.
Now I having this problem. The rpcbind listen 750/udp, and krb5kdc cannot start. This can be happen nearly every time I reboot.
Actually move this bug from F10Blocker to F10Target...
Portreserve went in several months ago CUPS uses it in its RPM package.
For other services, please open separate bug reports for them and assign them to the relevant package.