Bug 21326 - flock() does not work properly on 2.4 kernels
flock() does not work properly on 2.4 kernels
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Michael K. Johnson
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2000-11-25 09:12 EST by Nils Philippsen
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-28 01:15:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nils Philippsen 2000-11-25 09:12:08 EST
On my work machine, I run glibc-2.2-5 as well as linux-2.4.0-test10 and
-test11 and with both kernels, not more than 10 locks can be set on files
on the whole system (according to /proc/locks). If I switch to runlevel 1,
I'm able to flock() again (/proc/locks is empty beforehands). On my home
machine, I also run kernels 2.4.0-test10 and -test11, but glibc-2.1.92-14
and this error doesn't occur.

This program shows the error:

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main (int argc, char** argv) {
  int fd;

  fd = open ("/tmp/foo", O_CREAT|O_RDWR, 0644);

  if (flock (fd, LOCK_EX | LOCK_NB)) {
    perror ("flock()");
  } else {
    printf ("Locking succeeded.\n");

  close (fd);

On the machine at work, it looks like this:

nils@cognac:~/tmp/test> uname -a
Linux cognac 2.4.0-test11 #1 Mon Nov 20 08:08:50 CET 2000 i686 unknown
nils@cognac:~/tmp/test> ./foo
flock(): No locks available

At home, it's like this:

nils@wombat:~/tmp/test> uname -a
Linux wombat 2.4.0-test11 #11 SMP Sat Nov 25 12:59:41 CET 2000 i686 unknown
nils@wombat:~/tmp/test> ./foo
Locking succeeded.
Comment 1 Nils Philippsen 2000-11-27 02:39:29 EST
Hmm, I checked back with my work machine and it does show the error even
with glibc-2.1.92-14... I extended the test program to try POSIX lockf()
locks as well and they do succeed in any case:

--- 8< ---
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/file.h>
#include <fcntl.h>
#include <unistd.h>

int main (int argc, char** argv) {
  int fd;

  fd = open ("/tmp/foo", O_CREAT|O_RDWR, 0644);

  if (flock (fd, LOCK_EX | LOCK_NB)) {
    perror ("flock()");
  } else {
    printf ("Locking with flock() succeeded.\n");

  if (lockf (fd, F_TLOCK, 0)) {
    perror ("lockf()");
  } else {
    printf ("Locking with lockf() succeeded.\n");

  printf ("Waiting...\n");

  pause ();

  close (fd);
--- >8 ---

Now I'm a bit puzzled -- The only difference between the machines I can think
of is the Athlon processor in my work machine and the PII at home.

I tried the program on a dual PIII box running 2.4.0-test4 as well and both
tests succeed. I don't know whether the older kernel causes the tests not to
fail or the CPU (I can't upgrade the kernel there because it's a production
server and some people most likely would be pis^Wupset if I rebooted it).
Comment 2 Jakub Jelinek 2000-11-27 08:17:31 EST
Reassigning to kernel, glibc's flock is just plain assembly stub around
flock syscall, so it must be kernel issue.
Comment 3 Nils Philippsen 2000-11-28 01:15:18 EST
Just for the record: I don't think that it has any impact on the problem (*),
but I have installed a bunch of updated RPMS directly from porky, some of them
before QA passed.

(*): because e.g. the test program should really only depend on glibc and
the kernel (I would be seriously surprised if anything else had an influence
on it)
Comment 4 Nils Philippsen 2000-12-22 05:24:52 EST
I got back on this and tried it again with 2.4.0-test12 (and glibc-2.2-9 but
I doubt that this should matter for me after Jakub's comment) and apparently it
works. I didn't see anything related in the kernel changelogs, so I guess it's
either me seeing badly or that bug having been fixed either silently or

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