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): portmap-4.0-63
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