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.
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).
Reassigning to kernel, glibc's flock is just plain assembly stub around flock syscall, so it must be kernel issue.
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)
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 accidentally.