Bug 128540

Summary: file locking over NFS broken
Product: Red Hat Enterprise Linux 3 Reporter: Jeff Bastian <jmbastia>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: jakub, k.georgiou, pfrields
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-15 13:12:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
The lock2.c source code.
none
Kickstart file none

Description Jeff Bastian 2004-07-24 20:11:28 UTC
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 20:12:37 UTC
Created attachment 102196 [details]
The lock2.c source code.

Comment 2 Jakub Jelinek 2004-07-29 16:51:04 UTC
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 18:17:08 UTC
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 18:19:08 UTC
That means a kernel problem then.

Comment 5 Jeff Bastian 2004-07-29 18:31:50 UTC
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 21:19:41 UTC
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 15:14:34 UTC
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 20:39:27 UTC
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 20:46:20 UTC
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 13:12:28 UTC
I don't see a /sbin/chkconfig nfslock in the kickstart file.

Comment 11 Jeff Bastian 2004-10-15 23:01:57 UTC
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