Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 814133 - NFS and LDAP do not work because network is not up yet
Summary: NFS and LDAP do not work because network is not up yet
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: NetworkManager
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Dan Williams
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-19 09:56 UTC by Dennis Schridde
Modified: 2013-02-19 18:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-19 17:31:50 UTC
Target Upstream Version:


Attachments (Terms of Use)

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!


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