+++ 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): glibc-2.3.2-27.9 How reproducible: Depends entirely on the PID handed to ypbind on boot, and the exact set of services configured affects this. Suggested Fix: 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) 636 (LDAPS) 749 (Kerberos V kadmin) 873 (rsyncd) 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 name 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 blocker list....
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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. Closing.