An extensive discussion of this problem can be found in Red Hat's BTS, under ID# 103401. In particular, my assigning this bug to baselayout is motivated by that discussion. The issue is that various RPC services can get assigned port 631 (I've seen it happen with ypbind and amd) before cupsd starts up. Other services with well-known ports in the range used for RPC can be similarly affected. One could work around the problem by making sure that cupsd and other affected services are started before portmap (unless this introduces circular dependency loops, of course), but the solution proposed in the Red Hat bug record seems better. Reproducible: Sometimes Steps to Reproduce: 1.start some portmapped RPC services; they'll get assigned port numbers 2.try starting cupsd; if port 631 is already taken by an RPC service, you lose.
i dont think any of the solutions in that bug are acceptable ... obviously you dont want to mung up glibc's bindresvport() function as that sort of policy information should never be hardcoded into something like the system C library the only other solution offered there is "portreserve" which would require quite a bit of additional overhead to pretty much every single package out there which i really dislike heavily as you're basically making the other packages account for portmap/rpc shortcomings what would be nice is if the port binding were part of the rpc process ... that way we could have portmap tell the requesting RPC service the port they should use and then in portmap, have it check to see if the requested port exists in /etc/services ... this is actually a pretty simple algorithm, but unfortunately RPC does not work that way basically the answer is that if you utilize some rpc service that is randomly taking ports you need, then edit its conf.d script and give it the port # it should actually bind to for the applications that commonly cause problems (ypbind, rpc.*, etc...), i think we'll go the route of patching them with this simple algorithm
Created attachment 114328 [details] example of finding an unreserved port in /etc/services
Reopening, since the problem is not solved. Question about the example: serv = getservbyport(saddr.sin_port, "udp"); Shouldn't this be called with "tcp" or "udp" for SOCK_STREAM or SOCK_DGRAM, respectively?
none of my comments have been addressed, nor have my opinions changed, nor have you provided exact info on what is clashing on your system. i'm not changing glibc nor any non-rpc package. simply force proper port assignment in your /etc/conf.d/nfs to ranges you dont care about.
The problem here is ypbind (from net-nds/ypbind-1.19.1-r2), which sometimes ends up using tcp port 631, thus preventing cups from starting. > simply force proper port assignment in your /etc/conf.d/nfs to ranges you dont > care about. Looks like ypbind doesn't have an option for fixed port assignment.
(In reply to comment #5) > Looks like ypbind doesn't have an option for fixed port assignment. Oh well. Actually it has a -p option, but ypbind(8) doesn't mention it. :-( Sorry for the noise.
ypbind doesnt have a maintainer, so i imagine you could fix the man page yourself, or tweak the default conf.d in FILESDIR to note that -p is a useful one, or both ;).
Man page fixed, without revbump. (Several distros have a fix for this, so let's assume that somebody has already reported it upstream.)
i wonder if we could get by with selecting a default rpc port in the high unallocated range. or if that's asking for trouble.
(In reply to comment #9) > i wonder if we could get by with selecting a default rpc port in the high > unallocated range. or if that's asking for trouble. Hmm, practically I don't see why it wouldn't work, but I guess unassigned ports shouldn't be used like this. Why don't we patch ypbind with your function from comment #2? Looks like the cleanest solution to me.
