This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 53481 - File locking doesn't work over NFS
File locking doesn't work over NFS
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-09-10 05:28 EDT by Toralf
Modified: 2007-04-18 12:36 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-26 19:12:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Test program (1.21 KB, text/x-c)
2001-09-10 05:31 EDT, Toralf
no flags Details
rpcinfo/lsmod output (1.39 KB, text/plain)
2001-09-11 03:56 EDT, Toralf
no flags Details

  None (edit)
Description Toralf 2001-09-10 05:28:52 EDT
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
Comment 1 Toralf 2001-09-10 05:31:36 EDT
Created attachment 31436 [details]
Test program
Comment 2 Toralf 2001-09-10 05:59:50 EDT
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.
Comment 3 Bob Matthews 2001-09-10 11:39:52 EDT
Sounds like the lockd isn't running on the server.  What do "lsmod" and "rpcinfo
-p localhost" tell you when run on the server?
Comment 4 Toralf 2001-09-11 03:56:03 EDT
Created attachment 31577 [details]
rpcinfo/lsmod output
Comment 5 Toralf 2001-09-11 04:05:32 EDT
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.
Comment 6 Need Real Name 2001-11-06 04:31:50 EST
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.
Comment 7 Bob Matthews 2001-11-06 11:59:29 EST
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)
Comment 8 Toralf 2001-11-07 03:47:32 EST
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.
Comment 9 Toralf 2001-11-07 03:55:17 EST
Reopening as the value of the "Resolution:" field at least should be revised
based on my latest notes.

Note You need to log in before you can comment on or make changes to this bug.