[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