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
nils@wombat:~> grep '[^0-9]783/tcp' /etc/services
spamd 783/tcp # SpamAssassin Daemon
Version-Release number of selected component (if applicable):
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
rpc.mountd gets port 783/tcp
rpc.mountd doesn't get any port listed in /etc/services
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
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
> 1) make sure spamd startes before mountd
This may be unwise, because spamd can manipulate data that may in a mounted
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.
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.