Bug 814133 - NFS and LDAP do not work because network is not up yet
NFS and LDAP do not work because network is not up yet
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: NetworkManager (Show other bugs)
6.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Dan Williams
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-19 05:56 EDT by devurandom
Modified: 2013-02-19 13:19 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-19 12:31:50 EST
Type: Bug
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 devurandom 2012-04-19 05:56:43 EDT
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 10:07:26 EDT
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 devurandom 2012-04-26 09:30:56 EDT
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 Product and Program Management 2012-05-03 01:39:09 EDT
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 12:31:50 EST
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 devurandom 2013-02-19 13:19:49 EST
(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!

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