Bug 18097

The NFS locking bug between Red Hat Linux 7.0 and older versions of 
Red Hat Linux (6.2 in case of bug #18097, probably also 5.1, as it
is the most likely cause for bug #18075) may very well be the cause
of Pine hanging when trying to close a folder on a NFS-mounted partition
from a Red Hat Linux 5.1 server.

My mail server is on a SUN/OS 4.1.4 system.  I see the same symptoms as
described in bug #18097 when I connect a RedHat 7.0 system to my network and
access mail with pine.

As an FYI, I added a line to /etc/hosts containing my 7.0 system's IP address
and hostname, and then did a "service nfslock restart"; this allowed my system
to work as it did prior to the 7.0 upgrade...

we have simailar problem , we are trying to use RedHAt linux 7.0 as a nfs 
server.We are trying to mount the exported directory onto a SCO openserver 5.0.5
system.Read, write access is not a problem but file locking doesnot work even 
if we use no_auth_nlm or insecure_locks option

I was able to use ed@redhat's suggestion of putting an explicit IP to hostname
mapping in /etc/hosts on the client and restarting lockd. File locking was not
working before, and now it is. In my case, the server was RH6.2, the client was
RH7.

ed and ericb's suggestion of putting the hostname in the
/etc/hosts file on the client does not work for me. Situation: pine hangs on NFS
locking when *closing* folders, running on RH7.0. The home dir with the local
mail folders is mounted from a RH5.1 system (yes, it's old, yes it needs to be
upgraded).

This is a duplicate of the incorrectly closed 18938 bug and the currently open
bugs 21723 and 21957.  /etc/hosts has nothing to do with this bug.  The problem
is that lockd in nfs-utils 0.1.9.1-7 does not reliably start (and outputs no
diagnostic error messages when it fails).  For example, if you enable nfslock in
runlevel 5, the script will happily spit out "[ OK ]" following "Starting NFS
lockd:" though only rpc.statd continues to run while lockd dies when this bug
occurs.  Occasionally, lockd does start properly on boot, but I can reproducably
cause it to not start with "/etc/rc.d/init.d/nfslock stop" followed by
"/etc/rc.d/init.d/nfslock start".  As you can see, the presence or lack thereof
of the appropriate IP addresses in /etc/hosts is irrelevant at this stage;
however, I've always had all of my clients and servers' IP addresses in synch on
both clients and servers).

More strangeness with the locking problem. After running up2date on my RH7 box,
I no longer have functional locking between it and the RH6.2 nfs server. The
/etc/hosts trick above which fixed my problem originally seems to now have no
effect. I haven't figured out which upgraded rpm has caused the problem ... (I
suspect it may be glibc {2.2-9})

Sorry, but I have to disagree with jgotts -- for me, the problem most definitely
*was* fixed by adding the line to /etc/hosts (I tested it both with and without
the line several times, and it reliably failed without the line in /etc/hosts).

That said, I now seem to be in a similar situation as ericb, in that I recently
got the latest glibc update via up2date, and several days later had to reboot
the machine.  After the reboot, the line in the hosts file has no affect.  And
yes, lockd is running... :-)

This should be fixed with the rawhide nfs-utils, as rpc.statd no longer
runs chrooted.