Bug 112770 - ypbind hangs indefinitely when portmap is unreachable
ypbind hangs indefinitely when portmap is unreachable
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ypbind (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Klíč
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-30 20:51 EST by Ean J. Price
Modified: 2013-03-03 17:59 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-10 09:51:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ean J. Price 2003-12-30 20:51:51 EST
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:
Comment 1 Steve Dickson 2007-04-17 16:02:41 EDT
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
Comment 2 Karel Klíč 2010-05-10 09:51:46 EDT
The fix will not get into RHEL-3. Fixed in RHEL-5.
Comment 3 f_a_f12001 2010-05-11 03:38:17 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.