Description of Problem: It is not possible to lock files on a directory mounted via NFS. We have several hosts with the same setup, but the problem occurs only on some of them; I'm unable to figure out why. Version-Release number of selected component (if applicable): nfs-utils-0.3.1-5 + kernel-2.4.3-12 How Reproducible: Every time. Steps to Reproduce: 1. /usr/bin/gcc -O -g -Wunused -Wuninitialized flock.c -o flock (see attachment) 2. mount <nfs host>:<nfs directory> /u 3. ./flock /u/tst Actual Results: % ./flock /u/tst /u/tst... open(): Success fcntl(F_SETLKW): No locks available lockf(): No locks available close(): Success Expected Results: % ./flock /u/tst /u/tst... open(): Success fcntl(F_SETLKW): Success fcntl(F_SETLKW) (release): Success lockf(): Success lockf() (release): Success close(): Success Additional Information: These system log messages are possibly related to the problem: Sep 10 10:44:11 indonesia insmod: insmod: a module named lockd already exists Sep 10 10:46:19 indonesia kernel: lockd: cannot monitor 193.214.130.4 Sep 10 10:46:19 indonesia kernel: lockd: failed to monitor 193.214.130.4 Sep 10 10:46:19 indonesia kernel: lockd: cannot monitor 193.214.130.4 Sep 10 10:46:19 indonesia kernel: lockd: failed to monitor 193.214.130.4
Created attachment 31436 [details] Test program
The "insmod" message goes away if the host is set up so that nfsd module isn't loaded - e.g. if /etc/exports is empty. The other messages still occur every time the test program is executed, though.
Sounds like the lockd isn't running on the server. What do "lsmod" and "rpcinfo -p localhost" tell you when run on the server?
Created attachment 31577 [details] rpcinfo/lsmod output
lsmod/rpcinfo output from one of the servers is attached. I'm quite sure that it's a client issue, though; perhaps I wasn't clear enough on this, but I've tested with several different clients, and locking does work on some of them. Similarily, on a given client, I always get identical behaviour when connecting to different NFS servers running different OSs. I'm at my wit's end when it comes to working out what the difference between a working and a non-working setup is, though. But you are right, I've probably messed up the configuration somehow; I think the real "bug" here is that the lockd error messages don't really contain any useful information.
I have a similar problem with pine, it hangs while working with locks over mail folders mounted through nfs. The problem started after the last update to the system. Current system is RedHat 7.1 , kernel 2.4.9-6.
We believe that this problem is fixed by the latest errata kernels. Please try 2.4.9-12 (for RHL 7.1) and 2.4.9-13 (for RHL 7.2)
I still got this after upgrading to 2.4.9-13. I then noticed something that has escaped me earlier, however. I got the following messages on nfslock startup: Nov 7 09:21:24 indonesia rpc.statd[2410]: Version 0.3.1 Starting Nov 7 09:21:24 indonesia rpc.statd[2410]: open (state): Permission denied Nov 7 09:21:24 indonesia nfslock: rpc.statd startup succeeded The problem seemed to be that /var/lib/nfs/statd contained a number of files, including "sm", owned by root rather than rpcuser. I then did /etc/init.d/nfslock stop rm -rf /var/lib/nfs/statd/* /etc/init.d/nfslock start and everything worked! Points worth noticing: 1. I've upgraded the entire OS, and also installed several "nfs-utils" updates, since I started getting this problem, but it looks like the files have always survived. 2. "/etc/init.d/nfslock start" would report success ("[ OK ]"), when startup actually failed and the above mentioned error messages were written to the system log.
Reopening as the value of the "Resolution:" field at least should be revised based on my latest notes.