Re: NFS locking issues
* On Wed, Sep 04, 2002 at 03:37:07PM -0500, Kent West (email@example.com) wrote:
> nate wrote:
> > it was just a couple weeks ago I was trying to help others
> > on NFS and here I a asking something! doh!
> > anyways, I noticed recently that my NFS server at home seems to
> > have trouble with locking. I have 2 clients which use it to host
> > home directories(1 debian woody, 1 suse 8). I first noticed it about
> > a week ago when trying to load gnp (gnome notepad, my favorite X editor),
> > it didn't load, it just hung.. and i was getting this in my local(client)
> > kernel log:
> > Aug 25 13:56:37 aphro kernel: lockd: task 173568 can't get a request slot
> > Aug 25 13:57:59 aphro kernel: lockd: task 173597 can't get a request slot
> > Aug 25 13:58:49 aphro kernel: lockd: task 173597 can't get a request slot
> > Aug 25 13:59:39 aphro kernel: lockd: task 173597 can't get a request slot
> > Aug 25 14:00:29 aphro kernel: lockd: task 173597 can't get a request slot
> > Aug 25 14:01:19 aphro kernel: lockd: task 173597 can't get a request slot
> A few weeks ago I installed Debian Woody on a SunBlade 100 (Sun/Sparc)
> just to see what it was like. A few days before I had to reconvert it to
> Solaris for production use, I got it where it was mounting home
> directories via nfs (from a Solaris server). Everything worked fine for
> a few days, then when the other 35 machines in the area were imaged with
> Solaris and put on the network, but before people started logging in and
> using them, my Debian box started getting issues like what you describe.
> IIRC, it locked up the machine so I couldn't do anything but hard reset
> the box. Since I was about to convert the machine back to Solaris in a
> couple of days, I didn't try tracking it down, but thought I'd mention
> it here just in case it provides a piece to the puzzle.
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
I have had problems with NFS file locking as well. Some parts
of gnome like to use file locking, so with nfs mounted home
directories the users could not really run gnome properly.
After investigation it looks like the user space NFS server does
not do file locking but the kernel NFS server does. In debian
it is easy enough to switch. Just install the package
nfs-kernel-server and it automatically conflicts and removes
the user nfs server. I guess the kernel you are running would
need nfs built-in as well.
Now file locking is working over here and gnome is looking a lot
better. To actually test that file locking is really working here
are two ways to do it that dont need gnome.
1) Try getting mutt to read mail from a file on the NFS mounted directory.
If file locking is working, it will work. If file locking is not working
mutt will report an error and state the file is read-only.
2) There is a system call to lock a file or parts of a file. In the
Stevens book "Advanced Programming for the Unix Environment" there
is a whole section on file locking including a c program to lock files.
If locking is working this program runs without error. If locking does
not work, It reports some weird message. I can send you the code if you
want. The program is about 70 lines long, so I am not sure if I can
post it to the list. It exists on the net, also. I found it in a gnome
mailing list where Havoc Pennington posted it in response to a gnome
file locking problem. A google search on "NFS file locking gnome" might
be how I stumbled on it.
3) A gnome test is to start nautilus on the command line. It will spit
out a whole slew of error messages and then die if file locking isnt
working on the home directory of the user initiating nautilus.