[7.1-RELEASE-p2 amd64] NFS mount in fstab hangs during mountcritremote execution

Mel fbsd.questions at rachie.is-a-geek.net
Thu Jan 29 14:08:48 PST 2009


On Thursday 29 January 2009 00:47:49 Arjan van der Oest wrote:
> Hi,
>
> I’m puzzled and either I don’t understand the boot rc.d process or there is
> something wrong with it ☺
>
> I have this 7.1-RELEASE-p2 amd64 machine compiled with a GENERIC kernel, so
> NFS support is baked right into the kernel by default. In fsstab I have
> this entry:
>
> <nfs server ip>:/data/nfs-shares/S1018SR18 /nfs-mounts/backupsrv          
> nfs          rw            0    0
>

> - why does the system tries to mount the nfs filesystem from the fstab
> while nfs_client_enable has been set to no in rc.conf?

Because there is no relation between the two. You could be using a 3rd party 
nfs kernel module.

> - why does the 
> system seems to hang on the mountcritremote script although there seems no
> valid reason for that. I can imagine the network has not been fully
> configured yet when executing (indicated by the link UP message right after
> the mouning NFS filesystems line) but why will the script not continue
> after a few timeouts?

Because you are not aware of the following mount_nfs flags, you can put 
in /etc/fstab:

     -b      If an initial attempt to contact the server fails, fork off a
             child to keep trying the mount in the background.  Useful for
             fstab(5), where the file system mount is not critical to multi-
             user operation.

     -R      Set the mount retry count to the specified value.  The default is
             a retry count of zero, which means to keep retrying forever.
             There is a 60 second delay between each attempt.

     -i      Make the mount interruptible, which implies that file system
             calls that are delayed due to an unresponsive server will fail
             with EINTR when a termination signal is posted for the process.

     -s      A soft mount, which implies that file system calls will fail
             after retrycnt round trip timeout intervals.

> And more bizarre: when interrupting the 
> mountcritremote script the share has been actually mounted, so it seems the
> 'mount -a -t nfs' command has actually been executed successfully.

Looks more like the server is not sending a "success" message or it got lost 
in transit. If this is 100% reproducable, look into compatibility issues, by 
scaling down the NFS version for the mount and check firewall rules on both 
ends.

-- 
Mel

Problem with today's modular software: they start with the modules
    and never get to the software part.


More information about the freebsd-questions mailing list