On Mon, Dec 03, 2001 at 08:30:27PM -0600, David wrote: > I think that this is exactly the problem... I dont know if you are on > linux, but in my mounts through NIS to an HPUX machine from linux, I use > a 'nolock' option that disables attempting to lock over NFS, and I just > use dotlocking. I don't know where to point you for documentation on > this (perhaps `man mount`?), because I just guessed at what was > happening and the options, and it worked. > > This way I can still use FCNTL on my local machine (spool file), but > mutt doesn't try to specially lock my NFS folders.
Well, this was a tough one (short answer: nolock worked). The first sign of trouble was that the client is a 2.4.13 machine with a newer version of nfs than the server, which is an old RedHat 6.0 machine running 2.2.5-15. We noticed that statd was not running on the nfs server, so we started it. This caused both mutt and the program in my earlier mail to hang (presumably in an uninterubtible system call, since kill -9 could not kill the process). Perhaps this is why statd wasn't running in the first place. Next, after giving up on trying to get fcntl to work, we modified the local auto.master to use the nolock option, as you suggested. The format of this file differs on the client side from what ypcat gives, but after a number of reboots, we finally got nolock working. Now, mutt doesn't give me any error messages about fcntl (which, I suppose, means it is using dotlocking), and I can now postpone messages. Very cool. Thanks a bunch! Paul
