Description of problem: spamd (of spamassassin) would like to use port 783/tcp, but can't do this because rpc.mountd already uses this port, even though it is listed in /etc/services: [...] nils@wombat:~> grep '[^0-9]783/tcp' /etc/services spamd 783/tcp # SpamAssassin Daemon [...] Version-Release number of selected component (if applicable): portmap-4.0-56.1 How reproducible: Sometimes Steps to Reproduce: 1. (Stop spamd, Re)Start nfs (rpc.mountd) 2. (Re)Start spamassassin (spamd) 3. Lather, rinse, repeat until rpc.mountd mysteriously gets spamd's port Actual results: rpc.mountd gets port 783/tcp Expected results: rpc.mountd doesn't get any port listed in /etc/services Additional info: This could also be relevant for other daemons
mountd using the bindresvport() lib routine to bind a reserve port. bindresvport() starts at port 600 and works it way down until a free port is found or IPPORT_RESERVED-1 is reached (in this case an error is returned). So it not mountd ignorning defined service ports, its bindresvport() (which has been a problem since the beginning of time).... There are two workarounds to this problem 1) make sure spamd startes before mountd 2) explicitly set the port mound uses with the -d flag
Hmm, seems this has to be solved in glibc then (if it hasn't already), one way or another we should be able to specify ports that bindresvport() doesn't touch (be it via /etc/services or other means).
Nils is referring to Bug #102956 where spamassassin is still conflicting with this issue.
> 1) make sure spamd startes before mountd This may be unwise, because spamd can manipulate data that may in a mounted filesystem.
I can't find a bug number, but this has been certainly discussed in the past. Skipping priviledged ports that are in /etc/services is not a good idea, maybe our /etc/services is incomplete, but basically all numbers between 600 and 1023 are already assigned to some program, sometimes to several. I think the result was that this should be managed by initscripts daemon or something, that will prebind the ports that will be needed for services it is going to start and then free them when the services are going to start or something, but I don't remember details.
Although this was not the case before, you can now predefine all the ports the rpc daemons will use which really helps getting through firewalls as well as with this issue (I would suspect)....
See also bug #103401
Btw, comment #4 makes no sense. mountd is only involved in exporting filesystems, not in anything that the machine itself mounts.
Oops
This bug should be closed. glibc cannot be responsible for port reservations. It is impossible to look at /etc/services since, as said *many* times before, all the ports are officially allocated. Nils, just close it and find some other way. I though xinetd can help.