Red Hat Bugzilla – Bug 112770
ypbind hangs indefinitely when portmap is unreachable
Last modified: 2013-03-03 17:59:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Description of problem:
If portmap is made unavailable, through improperly set up netfilter
rules, ypbind will hang indefinitely and halt the boot process.
I had a student set up iptables rules to only allow access from the
local network. Essentially they did a:
iptables -A INPUT -s ! 192.168.0.0/24 -j REJECT
But forgot to allow traffic over the loopback. This prevented ypbind
from contacting the portmapper which then prevented the system from
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.set up NIS with authconfig
2.set up iptables rules that prevent traffic over the loopback
Actual Results: The system hung on /etc/rc.d/init.d/ypbind during bootup
Expected Results: ypbind should have timed out while trying to
contact portmap and failed gracefully so as not to prevent the system
from booting. If console access wasn't available this would have been
a real pain to fix ;)
I reworked the init script so the default wait time
should be 45sec. But this time is configurable by
changing the NISTIMEOUT variable. This should stop
the unreasonable long start up time.
Please try ypbind-1.19-9
The fix will not get into RHEL-3. Fixed in RHEL-5.
Still have the bug on RHEL5.3
When you prevent traffic over the loopback you have 2 choices with iptables, DROP or REJECT. And in practical there is really big difference, I like to use DROP instead of REJECT most of times on firewalls to save resources as the system will not reply back with error messages when we use DROP as we know.
When I used DROP to block the traffic over the loopback the system after rebooting stops on ypbind more than 10 minutes, I tried REJECT instead of DROP and tried to reboot again, The system stops for just seconds and continued to boot afterwords.
I think this still a bug, What ever what causes the prevention of contacting portmap the system should pass this and boot normally, As on a production system if the server hosts other services it may took along time to boot if ypbind or nfs services can't contact portmap.
What do think we should do, Or there is no solution.