Description of problem:
Cannot set a read or write lock on a file that has "group execute" bit set: e.g.
[tangzx2@mrtl4 temp]$ ls -ltr temp.txt
-rw-rwS--- 1 tangzx2 idev 347785 Jan 17 10:22 temp.txt
Could not get read lock on temp.txt
errno=37:No locks available
If I remove the S bit from temp.txt, then both read lock and write lock
the way the locking was invoked:
struct flock mylock;
mylock.l_len=0; /*lock entire file */
while (fcntl(fd,F_SETLK,&mylock) == -1)
fprintf (stderr,"Could not get read lock on %s
printf ("%s locked, trying again\n",filename);
* // from fstab
/dev/home_vg/lvol0 /home gfs defaults 0 0
[tangzx2@mrtl4 sbin]$ ./gfs_quota -V
gfs_quota 6.1.2 (built Jul 13 2005 16:42:11)
Copyright (C) Red Hat, Inc. 2004-2005 All rights reserved.
Version-Release number of selected component (if applicable):
When the group execute bit is sgid (setgroupid) on a file, mandatory file
locking is invoked. From the fcntl man page:
(Non-POSIX.) The above record locks may be either advisory or mandatory, and
are advisory by default. To make use of mandatory locks, mandatory locking must
be enabled (using the "-o mand" option to mount(8)) for the file system
containing the file to be locked and enabled on the file itself (by disabling
group execute permission on the file and enabling the set-GID permission bit).
Advisory locks are not enforced and are useful only between cooperating
processes. Mandatory locks are enforced for all processes.
This file has the setgid bit set but *not* the group execute bit, which doesn't
make a whole lot of sense, which is why it was chosen to indicate that mandatory
locking occur. GFS does not support mandatory locking.
What is interesting here is that the fcntl man page seems to indicate and the
permission bits must be set (group execute off, setgid on) *and* the "-o mand"
option is use to mount the filesystem. The "-o mand" option was not set, so I am
not sure why mandatory locking was attempted.