NFS based /usr prevents normal startup due to slow net init

[Mike Meyer]

In <015601c75ce9$d0263a10$b3db87d4 at multiplay.co.uk>, Steven Hartland <killing at multiplay.co.uk> typed:
> Another observation from my recent dealings with using
> NFS based /usr is that the remote critical mounts via
> nfs dont always give the network enough time to
> initialise before running. The first error displayed
> is:
> Mounting NFS file systems:mount_nfs: nfs1: hostname nor servname provided, or not known
> 
> This is particularly noticeable when the machine is
> connected to Cisco equipment as they take quite a
> while link to the connected host after initialisation.

> The result of this is that other services such as
> ldconfig fail to initialise properly due to the
> mount not being available until some point later
> in the boot process once link has been established.
> 
> Has anyone else experienced this?
> 
> Should mountcritremote use "mount -a -t nfs" when this
> appears to return after a short period without said FS's
> being successfully mounted? Is there a way to ensure that
> mount doesnt return without success i.e. a missing flag
> in my fstab or should mountcritremote be updated to test
> for failure and retry?

How about an extra flag in your fstab?  The default behavior for
mount_nfs is to keep retrying until the mount succeeds. For
non-critical file systems, you can specify -b to cause the mount
attempt to go into the background, and -R to limit the number of
retries. It sounds like you have one of those set.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.