https://bugzilla.novell.com/show_bug.cgi?id=231845#c23 --- Comment #23 from Neil Brown <nfbrown@novell.com> 2007-07-08 19:59:58 MST --- I would be very surprised if this bug affects SLES10-SP1 but not SLES10-GA (at least if it is a kernel bug). The problem is that since 2.6.12, the Linux NFS client simulates "flock" locks using "fcntl" locks on the server. This works fine *unless* a client tries to take both an "flock" and an "fcntl lock" on the same file at the same time and expects them both to succeed. This cannot work with the current Linux NFS implementation as the server will reject the second lock as it sees a conflict (for local filesystems, the locks are in separate address spaces, and no conflict is seen) So this will affect any kernel since 2.6.12 (which includes SLES10) running with any program that tries to get both a flock lock and an fcntl lock, which procmail does when compiled with LOCKINGTEST=101, but not when compiled with LOCKINGTEST=100. The best way to fix this problem for any given release is to change procmail to use LOCKINGTEST=100. To answer comment #20, you simply need to test if you can lock a file both ways at once. Something like: #include <stdlib.h> #include <stdio.h> #include <sys/file.h> #include <unistd.h> main() { int fd = open("afile", O_RDWR|O_CREAT,0600); if (flock(fd, LOCK_EX) < 0) { perror("Cannot get flock at all!!"); exit(2); } if (lockf(fd, F_TLOCK, 0) < 0) { perror("Cannot get lockf while holding flock"); exit(1); } printf("Successfully got both locks\n"); exit(0); } Tested and seems to work. When run in an NFS directory I get: Cannot get lockf while holding flock: Resource temporarily unavailable -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.