Hi,
I'm trying to investigate why my apache compiled with
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 (and glibc 2.2
build against 2.4.0-test10 headers) immediately dies with
[emerg] (11)Resource temporarily unavailable: fcntl:
F_SETLKW: Error getting accept lock, exiting!
This happens while trying to get the file lock to serialize accept.
The first child gets the lock, the other should block.
However, fnctl(fd, F_SETLKW, ...) returns with EAGAIN
(which shouldn't be possible, it would be correct for F_SETLK).
Note that for the above compile flags, libc's F_SETLKW is 14 (on i386)
which in the kernel is F_SETLKW64 (kernel's F_SETLKW is 7).
strace shows that the actual system call used by libc is fcntl64.
For 2.4.0-test11, fs/fcntl.c has the following code:
asmlinkage long sys_fcntl64(unsigned int fd, unsigned int cmd, unsigned long arg
)
{
...
switch (cmd) {
case F_GETLK64:
err = fcntl_getlk64(fd, (struct flock64 *) arg);
break;
case F_SETLK64:
err = fcntl_setlk64(fd, cmd, (struct flock64 *) arg);
break;
case F_SETLKW64:
err = fcntl_setlk64(fd, cmd, (struct flock64 *) arg);
break
...
i.e. fcntl_setlk64() is called with cmd==F_SETLKW64,
but in fs/locks.c:
int fcntl_setlk64(unsigned int fd, unsigned int cmd, struct flock64 *l)
{
...
error = posix_lock_file(filp, file_lock, cmd == F_SETLKW);
^^^^^^^^
where the last argumet to posix_lock_file governs
wait vs. immediate return.
Cheers, Roderich
--
"Thou shalt not follow the NULL pointer
for chaos and madness await thee at its end."
Roderich Schupp mailto:[email protected]
ExperTeam GmbH http://www.experteam.de/
Munich, Germany