Bug 430825 - RPC port selection for ypbind may collide with CUPS port on boot
RPC port selection for ypbind may collide with CUPS port on boot
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
: 168996 (view as bug list)
Depends On:
Blocks: F10Target
  Show dependency treegraph
Reported: 2008-01-29 18:14 EST by Jon Stanley
Modified: 2013-01-10 08:39 EST (History)
37 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-09 05:09:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jon Stanley 2008-01-29 18:14:44 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):

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().
Comment 1 Bill Nottingham 2008-01-29 18:22:25 EST
*** Bug 168996 has been marked as a duplicate of this bug. ***
Comment 2 Bill Nottingham 2008-01-30 12:28:24 EST
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.
Comment 3 Matthew Galgoci 2008-01-30 12:37:05 EST
the latter solution of just grabbing ports that don't return names looks like
the cleanest imho.

Comment 4 Steve Dickson 2008-02-01 03:24:48 EST
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. 
Comment 5 Bill Nottingham 2008-02-01 12:12:16 EST
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.
Comment 6 Steve Dickson 2008-02-01 14:40:09 EST
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. 

Comment 7 Jesse Keating 2008-04-01 17:04:17 EDT
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.
Comment 8 Vitezslav Crhonek 2008-04-02 07:11:14 EDT
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.
Comment 9 Tim Waugh 2008-04-02 07:53:35 EDT
Has portreserve been ruled out?
Comment 10 Tim Waugh 2008-04-02 13:46:46 EDT
See https://bugzilla.redhat.com/show_bug.cgi?id=103401#c5 for when portreserve
was first mentioned (2003!).
Comment 11 Bill Nottingham 2008-04-02 14:24:02 EDT
I don't like solutions that involve modifying every package if it can be avoided...
Comment 12 Jon Stanley 2008-04-16 21:04:28 EDT
is this really a F9 blocker if it's been like this for years?  I'm reviewing the
blocker list....
Comment 13 Jon Stanley 2008-04-16 21:06:48 EDT
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.
Comment 14 Tim Waugh 2008-04-17 04:17:09 EDT
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.
Comment 15 Sitsofe Wheeler 2008-04-20 06:13:20 EDT
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.
Comment 16 Jeremy Sanders 2008-04-20 07:02:59 EDT
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?
Comment 17 Bug Zapper 2008-05-14 00:55:34 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 18 Jesse Keating 2008-10-03 19:00:19 EDT
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.
Comment 19 Kazutoshi Morioka 2008-10-03 23:07:05 EDT
Now I having this problem. The rpcbind listen 750/udp, and krb5kdc cannot start. This can be happen nearly every time I reboot.
Comment 20 Matthias Clasen 2008-10-08 13:36:20 EDT
Actually move this bug from F10Blocker to F10Target...
Comment 21 Tim Waugh 2008-10-09 05:09:20 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.