Bug 441463 - netfs starts too early after networking
Summary: netfs starts too early after networking
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: NetworkManager
Version: 5.0
Hardware: x86_64
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Dan Williams
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-08 08:47 UTC by Andy
Modified: 2013-07-18 20:59 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-18 20:59:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Andy 2008-04-08 08:47:18 UTC
Description of problem:
On boot.
Netfs starts too early after networking, this causes nfs shares to fail because
the host is not resolvable while networking is starting.

Version-Release number of selected component (if applicable):
initscripts-8.45.17.EL-1.el5.centos.1

How reproducible:
boot server with an nfs share.
  
Actual results:
on boot - when start scripts are scrolling it says.
Mouting NFS filesystems mount : mount to NFS server "192.168.0.102" failed:
system error : no route to host

once server fully booted. Log on and then type "mount -a"
the NFs share mounts fine then.

Expected results:
It should mount it fine


Additional info:

The fix :
edit /etc/init.d/netfs
Add this line :  action $"Sleeping for 60 secs: " sleep 60    

So the file now reads :
  [ ! -f /var/lock/subsys/portmap ] && service portmap start
       action $"Sleeping for 60 secs: " sleep 60
            action $"Mounting NFS filesystems: " mount -a -t nfs,nfs4


Website :
http://crazytoon.com/2007/05/11/centos-and-redhat-problem-nfs-mount-at-boot-up-fails-with-error-system-error-no-route-to-host/

Comment 1 Rob Garth 2008-11-11 00:50:14 UTC
Moving NTP will fix the problem. I hadn't realised there was already an option to synchronise time before starting ntpd. With that option turned on, as long as ntpd starts before netfs, this bug goes away.

Comment 2 Don Hoover 2009-03-16 20:00:47 UTC
This ALSO SHOWS up on a system that is an NFS client of itself, because the NFS server does not startup until way later after netfs ties to mount the NFS moint points in /etc/fstab.

NTP will *NOT FIX* this issue.

Netfs needs to come after the nfs server startup.

Comment 3 Rob Garth 2009-03-16 22:59:16 UTC
My comment appeared on the wrong bug. Must have made a booboo sorry, My problem was specific to ntfs4, and this comment is on the wrong bug - sorry.

Comment 4 Don Hoover 2010-05-20 20:41:45 UTC
This is still an issue in RHEL 5.5.

Updated a system to rhel 5.5 and had to manually reorder the init scripts from the default for a nfs server that mounted shares from itself.

Comment 5 Carlo de Wolf 2012-09-26 11:41:53 UTC
While I encountered some old machines, the real issue appears to be some timeout waiting for the arp table to properly fill.

So I added the following lines below portmap start:

            # bug 441463
            ping -c 1 192.168.102.1 >/dev/null
            action $"Waiting for gateway to appear: " eval "arp 192.168.102.1 >/dev/null"

Comment 6 Dan Williams 2013-02-19 05:34:33 UTC
If NetworkManager is enabled, does setting NETWORKWAIT=yes in /etc/sysconfig/network fix the issue?  That will wait up to 30 seconds for a network connection to start, and will exit when the shorter of (a) 30 seconds or (b) a network connection has occurred.  That should ensure that the NFS server can be found before any further scripts can proceed.

Comment 7 Dan Williams 2013-07-11 02:03:38 UTC
Has anyone been able to check whether the NETWORKWAIT=yes fixes the issue?

Comment 8 Rashid Khan 2013-07-18 20:59:27 UTC
Due to lack of response for 5 months closing the issue for now.
If this is super critical and has to be fixed for the 5.10 or 5.11 release then please reopen it with enough information to qualify this issue as a critical item for the release. 

Thanks


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