Bug 128540 - file locking over NFS broken
file locking over NFS broken
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-24 16:11 EDT by Jeff Bastian
Modified: 2015-01-04 17:08 EST (History)
3 users (show)

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


Attachments (Terms of Use)
The lock2.c source code. (1.31 KB, text/plain)
2004-07-24 16:12 EDT, Jeff Bastian
no flags Details
Kickstart file (5.00 KB, text/plain)
2004-08-13 16:46 EDT, Jeff Bastian
no flags Details

  None (edit)
Description Jeff Bastian 2004-07-24 16:11:28 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040623

Description of problem:
Using fcntl() to lock files on an NFS mount doesn't work on RHEL3 U3 beta.

Below is a short C program that locks a file stored on an NFS mounted
directory.  This program works on RHEL3 U2, but fails to achieve a
lock on U3-beta.


#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/file.h>
#include <errno.h>
#include <string.h>

#define NFSFILE "/data/dump/test.lock"
#define LOCALFILE "/tmp/testjb.lock"

void lockFile(char*);

int main()
{
    lockFile(NFSFILE);
    lockFile(LOCALFILE);
}

void lockFile(char *path)
{
    struct flock myLock;
    int status;
    int fd;
    char junk;

    printf("%s\n", path);

    fd = open(path, O_WRONLY | O_CREAT, 00664 );
    printf("  fd(%d)\n",fd);
    if (fd == -1)
    {
        printf("  error(%s)\n", strerror(errno));
    }
    else
    {
        /* status = flock(fd, LOCK_EX ); */
        memset(&myLock, 0, sizeof(myLock));
        myLock.l_type = F_WRLCK;
        status = fcntl(fd, F_SETLKW, &myLock);

        /* printf("  flock(%d)\n", status); */
        printf("  fcntl(%d)\n", status);

        if (status == 0)
        {
            printf("  Success!\n");
            /* flock(fd, LOCK_UN); */

            printf("...Hit <ENTER> to unlock...\n");
            scanf("%c", &junk);

            myLock.l_type = F_UNLCK;
            fcntl(fd, F_SETLK, &myLock);
        }
        else
        {
            /* printf("  Failed...\n"); */
            perror("  Failed:");
        }
    }

    /* close and remove test file */
    close(fd);
    unlink(path);
}


Version-Release number of selected component (if applicable):
glibc-2.3.2-95.24

How reproducible:
Always

Steps to Reproduce:
1. gcc -o lock2 lock2.c
2. Run ./lock2 on RHEL3 U2
3. Run ./lock2 on RHEL3 U3-beta
    

Actual Results:  $ ./lock2 
/data/dump/test.lock
  fd(3)
  fcntl(-1)
  Failed:: No locks available
/tmp/testjb.lock
  fd(3)
  fcntl(0)
  Success!
...Hit <ENTER> to unlock...


Expected Results:  $ ./lock2 
/data/dump/test.lock
  fd(3)
  fcntl(0)
  Success!
...Hit <ENTER> to unlock...

/tmp/testjb.lock
  fd(3)
  fcntl(0)
  Success!
...Hit <ENTER> to unlock...


Additional info:

I tried downgrading the kernel to 2.4.21-15.EL (the kernel from U2)
but the bug was still present, so I'm guessing the bug is in glibc.
Comment 1 Jeff Bastian 2004-07-24 16:12:37 EDT
Created attachment 102196 [details]
The lock2.c source code.
Comment 2 Jakub Jelinek 2004-07-29 12:51:04 EDT
It is highly unlikely this is glibc related.
You can run the program under strace in both RHEL3-U2 and U3-beta
to see what the difference is, though to my knowledge there were
no related changes in glibc.
What kerenl were you running on the NFS server side?
Comment 3 Jeff Bastian 2004-07-29 14:17:08 EDT
Our NFS servers are all NetApp filers.  We're currently running 
  NetApp Release 6.4.4R1P15
on the filers.

Running the same program through strace, here are the two calls to
fcntl64():

RHEL3 U2:
open("/data/dump/test.lock", O_WRONLY|O_CREAT, 0664) = 3
write(1, "  fd(3)\n", 8  fd(3)
)                = 8
fcntl64(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0


RHEL3 U3-beta:
open("/data/dump/test.lock", O_WRONLY|O_CREAT, 0664) = 3
write(1, "  fd(3)\n", 8  fd(3)
)                = 8
fcntl64(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0})
= -1 ENOLCK (No locks available)



As you can see, the calls are the same on both, but on U3-beta an
error gets returned to it.
Comment 4 Jakub Jelinek 2004-07-29 14:19:08 EDT
That means a kernel problem then.
Comment 5 Jeff Bastian 2004-07-29 14:31:50 EDT
However, I tried downgrading just the kernel and using the
2.4.21-15.EL U2 kernel, and the file locking still didn't work, which
led me to believe it's somewhere else.  Possibly a combination of the
kernel and glibc?

For a sanity check, I just tried it again.  I'm running U3-beta with
the U2 kernel and it fails with the same error: No locks available.
Comment 6 Jeff Bastian 2004-08-12 17:19:41 EDT
This also affects Gnome and Cadence, too.  I just tried using Gnome on
RHEL3 U3-beta with my 'dummy' test account and an error message popped
up saying
  Please contact your system administrator to resolve the following
  problem: 
  Could not lock the file "/home/dummy/.gconf-test-locking-file";
and continues to give dtails about rpc.statd and rpc.lockd.
Comment 7 Steve Dickson 2004-08-13 11:14:34 EDT
Your lock program seems to work for me on both the U3 beta
and U2.... The only way I could get it to fail was to
stop rpc.statd. So are you sure rpc.statd is running on the 
client? What does "service nfslock status" say? Also,
do /var/log/messages have anything interesting? 
Comment 8 Jeff Bastian 2004-08-13 16:39:27 EDT
You're right - rpc.statd is *not* running.  I enabled it and now file
locking works with my example program, Gnome, and Cadence.

So now the question is - why isn't rpc.statd running?  chkconfig shows
it was never added as a default service:

$ chkconfig nfslock --list
service nfslock supports chkconfig, but is not referenced in any
runlevel (run 'chkconfig --add nfslock')

I enabled it and rebooted and everything is working.

I also kickstarted the machine again just to be sure I didn't
accidentally disable nfslock somehow and after a fresh kickstart,
nfslock was not an enabled service.  My kickstart file is almost
identical to the one I used for U2 except the nfs line is different to
point to the U3-beta ISO images.

I'll attach my kickstart file, passwords stripped of course.
Comment 9 Jeff Bastian 2004-08-13 16:46:20 EDT
Created attachment 102723 [details]
Kickstart file

My U3-beta kickstart file with passwords and IP addresses and things stripped
out for security.
Comment 10 Steve Dickson 2004-10-15 09:12:28 EDT
I don't see a /sbin/chkconfig nfslock in the kickstart file.
Comment 11 Jeff Bastian 2004-10-15 19:01:57 EDT
It's never been necessary to run 'chkconfig nfslock on' before.  And
now that U3 is out of beta, it's still not necessary, so whatever was
broken in U3-beta has been fixed.  I guess this bug can be closed now.

Thanks anyway!
Jeff

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