Red Hat Bugzilla – Bug 187840
portmap picks random ports -> breaks other services
Last modified: 2011-12-08 10:40:05 EST
Description of problem:
All the NIS services pick a random port when starting, which can break other
programs that start later. I most recently saw this with ypbind starting on
port 783, which broke spamassassin. I've previously seen this with a YP service
breaking cups (all the cups clients tried reconnecting several times/second,
which led to an iptables connection tracking DDoS against my server). That had
apparently been fixed in FC and RHEL3 by moving S90cups to S55cups, so I'm
guessing a similar fix is in order for spamassassin. But I'm filing this bug
against portmap since it's the YP services that are causing all the problems in
the first place, and a cleaner fix might be to implement a "blacklist" of
disallowed ports. (Some day, dependencies might require yp/nis to start before
something else, and the port randomization will bite you.)
Note that similar bugs have been reported against RH8 in bug 85149 and against
FC4 in bug 168996. I'm adding this bug against RHEL4 in hopes that maybe it'll
get noticed/fixed sometime soon.
Version-Release number of selected component (if applicable):
I believe most NIS process have a '-p' flag that will define the port
they uses. Unfortunately I believe this is the only method avaiable
at the moment..
Closing bug reports that have been causing machines to misbehave for years is
not acceptable. Please don't try that again.
I previously suggested two solutions to this bug. While the first solution
(reordering services) sounds simpler (and seems to be the approach RH has
taken), it does have the problem that it's conceivable that dependencies will
cause problems. Blacklisting all ports listed in /etc/services is likely the
best solution -- I once checked and discovered that it's actually a fairly
sparse file. So that solution should work quite well. I even tried figuring
out how to code a patch for that, but haven't had time. If RH is unwilling to
commit resources to this, then reporting the bug (and suggested fix) upstream
would be advisable.
This problem bit me with Fedora Core 5.
portmap used port 631 for ypserv.
Cups failed to start, samba failed due to missing cups and stopped the the whole
boot propcess. Thus preventing other services from starting and reaching their
post-boot state etc.. That should make clear how serious the consequences are.
Another suggestion: do not take ports below 10000. Not waterproff, but it's an
improvement which helps in many cases. This improvement would not depend on
/etc/services or the fragile S?? init number allocation, preventing admins from
digging their own graves if they reorder the init scripts.
rpm -iq portmap says:
Version: 4.0, Vendor: Red Hat, Inc., Release: 65.2.2
*** Bug 227411 has been marked as a duplicate of this bug. ***
I just hit this today after installing the RHEL4 spamassassin errata!
Upon a reboot, portmap assigned port 783 to rpc.statd and so spamd refused to
start. So guess where I assumed the problem was? That's right... the errata
update! While I was forced to dig into this to effect a resolution, mail was
not being processed as this server was the mailhub! Does Red Hat really think
that pissing off CEOs will endear them to the idea of the CIO throwing more
money at Red Hat Network subscriptions if such activity doesn't result in the
problem getting fixed?
If I were to fix this, I would probably make portmap avoid any port assigned to
services listed in /etc/services; but that wouldn't work here because
spamassassin's use of port 783 isn't in /etc/services either!!
Since it's clear that redhat has no intention of fixing this bug, I'll document the workaround for everyone else:
echo "YPSERV_ARGS=--port 892" >> /etc/sysconfig/network
echo "YPPASSWDD_ARGS=--port 723" >> /etc/sysconfig/yppasswdd
echo "RPCMOUNTDOPTS=--port 1021" >> /etc/sysconfig/network
echo "RPCRQUOTADOPTS=--port 969" >> /etc/sysconfig/network
You may wish to choose different port numbers -- these come from a successful boot of a fairly active server, and have been confirmed to not exist in /etc/services.
Oops, one more:
echo "STATD_PORT=804" >> /etc/sysconfig/nfs