From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031117 Firebird/0.7 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 booting. Version-Release number of selected component (if applicable): ypbind-1.12-1 How reproducible: Always Steps to Reproduce: 1.set up NIS with authconfig 2.set up iptables rules that prevent traffic over the loopback 3.reboot 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 ;) Additional info:
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.