Bug 154800

I see in

https://www.redhat.com/archives/fedora-list/2005-January/msg04804.html

that you may be able to add a -p PORT line to the ypserv command line. I think
something like

YPSERV_ARGS=-p 900

in /etc/sysconfig/network may fix this problem (if other rpc programs don't get
there first). I haven't tried this out on our server with this problem yet.

RedHat/Fedora should probably set the programs which dyanamically assign rpc
ports to fixed locations by default (or a sensible range of ports), to prevent
this random failure.

Looking at the source for ypserv, the appropriate section is

  else
    my_socket = RPC_ANYSOCK;

  transp = svcudp_create (my_socket);
  if (transp == NULL)
    {
      log_msg ("cannot create udp service.");
      exit (1);
    }

So, it looks to be a glibc issue. Shouldn't glibc avoid using ports that are
defined in the /etc/services file?

Jeremy's observation in comment #2 about glibc components avoiding ports in
/etc/services seems valid to me so I'm assigning this to Jakub. However, in
fairness I don't think the imap ports were added to the setup rpm (which
contains /etc/services) until version setup-2.5.34-1 on Sept 23 2004. I'm not
100% sure which rpm the secure pop/imap ports made their debut in but the point
is it wasn't that long ago, so perhaps glibc is correctly avoiding ports defined
in /etc/services but the SSL imap ports were absent in the version of the file
where this occurred. But I think Jakub can quickly answer whether /etc/services
ports are sacrosanct.

glibc (bindresvport in particular) intentionally doesn't skip any /etc/services
ports, because almost all are reserved for something and some sunrpc users like
nfs mounting need sometimes hundreds of the reserved ports.
See e.g. #154678 for details.  The fact that some port is listed in /etc/services
doesn't mean it will be actually used for that service on this box, in fact
usually it does not.  So, either the boot sequence makes sure services that
need the fixed reserved ports are started before those using bindresvport,
there should be a deamon (or initscripts itself) that is told about what
ports will all services it is going to start need and reserve the ports for them
early and then pass them over to the daemons.

After a bit of investigation I discovered this is a well known problem (bug
#103401) with a solution (see that bug report). I'm marking this as a duplicate
of 103401 and I'll volunteer to take ownership of the portresve package if we
can get agreement to put it in the distribution.

*** This bug has been marked as a duplicate of 103401 ***

(In reply to comment #5)
> After a bit of investigation I discovered this is a well known problem (bug
> #103401) with a solution (see that bug report). I'm marking this as a duplicate
> of 103401 and I'll volunteer to take ownership of the portresve package if we
> can get agreement to put it in the distribution.

I do not agree. IMO, the solution is that mentioned in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103401#c1
which would mean a major redesign of the initscripts.

It's not a major redesign, its a matter of adding one line to invoke
portrelease, that doesn't sound very complicated (and requiring the installation
of the portreserve package).

Since there is a strong resistence to modifying glibc (see Jakub and Ulrich's
comments) and has been pointed out in several comments there is a cyclical
dependency on initscript ordering then please offer a better solution that has a
consensus for adoption.

I think Tim's portrelease has the potential for a race condition, but at the
moment it seems very low risk.

Also I think portrelease needs to be modified to persist to reclaim a reserved
port if the service shuts down in the initscript, that would make two lines in
the initscript that needs to be added, one in start() and one in stop().

(In reply to comment #7)

> Since there is a strong resistence to modifying glibc (see Jakub and Ulrich's
> comments) and has been pointed out in several comments there is a cyclical
> dependency on initscript ordering then please offer a better solution that has a
> consensus for adoption.
Counter question: How do other OSes (BSD, Solaris) and Linux distributions
(Debian, SuSE) solve this issue? Esp. knowing what SuSE does would be
interesting, because they dynamically assign initscript priorities.

As portmap, yp* etc. are widely used on various OSes, as this problem is not new
(> 15 years), I would be surprised if there wasn't a commonly accepted solution. 

(In reply to comment #8)

I had this problem (631 port reservation) between cups and ypbind, then I
contacted Thorsten Kukuk.
I don't speak on behalf of suse, but Thorsten Kukuk (ypbind maintainer) told me
in a message that :
 "(suse) have a blacklist of which ports RPC based programs are not allowed to use."

In RHEL 4, the upbind man page is false, the upbind has a "-p" parameter witch
allow to bind it to a specific port.

denis