Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 430825 - RPC port selection for ypbind may collide with CUPS port on boot
Summary: RPC port selection for ypbind may collide with CUPS port on boot
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 9
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 168996 (view as bug list)
Depends On:
Blocks: F10Target
TreeView+ depends on / blocked
 
Reported: 2008-01-29 23:14 UTC by Jon Stanley
Modified: 2018-12-02 15:08 UTC (History)
37 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-09 09:09:20 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Jon Stanley 2008-01-29 23:14:44 UTC 
+++ 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().
Comment 1 Bill Nottingham 2008-01-29 23:22:25 UTC 
*** Bug 168996 has been marked as a duplicate of this bug. ***
Comment 2 Bill Nottingham 2008-01-30 17:28:24 UTC 
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.
Comment 3 Matthew Galgoci 2008-01-30 17:37:05 UTC 
the latter solution of just grabbing ports that don't return names looks like
the cleanest imho.
Comment 4 Steve Dickson 2008-02-01 08:24:48 UTC 
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 17:12:16 UTC 
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 19:40:09 UTC 
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 21:04:17 UTC 
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 11:11:14 UTC 
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 11:53:35 UTC 
Has portreserve been ruled out?
Comment 10 Tim Waugh 2008-04-02 17:46:46 UTC 
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 18:24:02 UTC 
I don't like solutions that involve modifying every package if it can be avoided...
Comment 12 Jon Stanley 2008-04-17 01:04:28 UTC 
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-17 01:06:48 UTC 
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 08:17:09 UTC 
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 10:13:20 UTC 
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 11:02:59 UTC 
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 04:55:34 UTC 
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
Comment 18 Jesse Keating 2008-10-03 23:00:19 UTC 
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-04 03:07:05 UTC 
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 17:36:20 UTC 
Actually move this bug from F10Blocker to F10Target...
Comment 21 Tim Waugh 2008-10-09 09:09:20 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.