Bug 814133

Summary: NFS and LDAP do not work because network is not up yet
Product: Red Hat Enterprise Linux 6 Reporter: Dennis Schridde <devurandom>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED WORKSFORME QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2CC: rkhan, tpelka
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-19 17:31:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Dennis Schridde 2012-04-19 09:56:43 UTC 
Description of problem:
On all our machines we have the problem that most of the time NFS fails to mount and LDAP fails to authenticate, because the network is not up at the time it is required (that is our assumption, at least). We have to workaround this with two lines in /etc/rc.local:
service netfs restart
service nslcd restart

Version-Release number of selected component (if applicable):
NetworkManager-0.8.1-15.el6.x86_64

How reproducible:
Install nss-pam-ldapd and setup LDAP using authconfig with forcelegacy.
Setup some NFS mounts in /etc/fstab.
Boot your computer and observe that NFS dirs are not mounted, authentication and uid/gid-to-name solution does not work.

Workaround:
/etc/sysconfig/network-scripts/ifcfg-eth0:
NM_CONTROLLED="no"
BOOTPROTO="dhcp"

# chkconfig NetworkManager off
# chkconfig --del NetworkManager

This workaround still only works most of the time, because sometimes the network interface fails to get a carrier signal in time, and dhcp fails.
Comment 2 Dan Williams 2012-04-19 14:07:26 UTC 
Another thing to try is putting NETWORKWAIT=true into /etc/sysconfig/network; that'll make the initscripts wait for NM to bring up the network, or 30 seconds, whichever happens first.  That basically switches on the old behavior of waiting for a network interface to start up before continuing with the bootup.
Comment 3 Dennis Schridde 2012-04-26 13:30:56 UTC 
Putting NETWORKWAIT=yes into /etc/sysconfig/network works.

Gentoo/Linux sets the status of the NetworkManager service to "starting" (instead of "stopped" or "started") until the network is announced as up by nm-online - this way the init system (OpenRC) will know that it has to wait until it may start other services depending on the network. Maybe that would be an option for RHEL, too?
Comment 4 RHEL Program Management 2012-05-03 05:39:09 UTC 
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 5 Dan Williams 2013-02-19 17:31:50 UTC 
The problem in RHEL6 is that the init system is simply not intelligent enough to handle dependencies and parallelizing scripts.   That's fixed in later releases with systemd, where this is not a problem.

Unfortunately, since sysvinit is pretty dumb, and everything is serialized with hardcoded dependencies, there's no other way to fix it except with NETWORKWAIT.
Comment 6 Dennis Schridde 2013-02-19 18:19:49 UTC 
(In reply to comment #5)
> The problem in RHEL6 is that the init system is simply not intelligent
> enough to handle dependencies and parallelizing scripts.   That's fixed in
> later releases with systemd, where this is not a problem.
> 
> Unfortunately, since sysvinit is pretty dumb, and everything is serialized
> with hardcoded dependencies, there's no other way to fix it except with
> NETWORKWAIT.

Thanks for your answer!