Description of problem: Cannot set a read or write lock on a file that has "group execute" bit set: e.g. (see red) * [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 worked fine. the way the locking was invoked: * struct flock mylock; mylock.l_type=F_RDLCK; mylock.l_len=0; /*lock entire file */ mylock.l_whence=SEEK_SET; mylock.l_start=0; while (fcntl(fd,F_SETLK,&mylock) == -1) { if (errno!=EAGAIN) { fprintf (stderr,"Could not get read lock on %s errno=%d:",filename,errno); perror (""); exit(1); } printf ("%s locked, trying again\n",filename); } GFS environment: * // from fstab /dev/home_vg/lvol0 /home gfs defaults 0 0 // version [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): RHEL4/GFS6.1
When the group execute bit is sgid (setgroupid) on a file, mandatory file locking is invoked. From the fcntl man page: -- Mandatory locking (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.