02-03-2009 10:22 AM
OSF1 lapacho V5.1 2650 alpha
Folks, having some NFS client issues on a Tru64 machine. Some sort of stale file handle between the Tru64 box and a RHEL4.7 NFS server.
I ran /sbin/init.d/nfsmount stop -- which complained about some other NFS mounts in use. I killed the processes locking those and unmounted them.
However, running nfsmount now:
# ./nfsmount start
Mounting NFS filesystems
NFS2 server lapacho not responding still trying
Why it's trying to talk to itself, I don't know. I tried restart the nfs daemon to no avail, commands like df just hang and don't respond to kill -9 either.
The users on this box really do not want to reboot it -- what else can be done to just kill all this NFS stuff? I suppose I need to start killing random processes that may be locking things...
Is there a way to find out what's mounted currently on the system (cat /proc/mounts in Linux) or something like lsof to see what open file handles there are? I guess fuser would work perhaps...
02-04-2009 03:20 PM
What machine is the server?
What machine is the client?
Please specify (extracts from) /etc/exports and /etc/fstab
NFS must be started on the NFS server machine with /etc/exports
On the client machine you need to have /etc/fstab and use mount to mount the remote file system.
Why are you using NFS2 and not NFS3?
02-04-2009 03:39 PM
I don't know why it reported the NFSv2 error. The server in question is itself -- why it would be trying to talk to its own NFS server using v2 is beyond me. :-)
In any case, the automount process was in an uninterruptible sleep state with a parent process of "1", so there was no way to kill it without rebooting.
I rebooted and disabled the old "automount" daemon which I am told can get confused fairly easily. In its place we're using autofs which I'm hopeful will be a little bit more robust.
Still not totally clear what happened on this machine to cause the issues but everything is back to normal for the moment.