https://bugzilla.novell.com/show_bug.cgi?id=231845 okir@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nfbrown@novell.com Status|NEEDINFO |NEW Info Provider|okir@novell.com | ------- Comment #5 from okir@novell.com 2007-01-08 05:59 MST ------- Could be a kernel change, indeed. The curious thing in the trace from comment #2 is that procmail tries to use both posix and bsd locking. The fcntl(SETLK) succeeds, but flock(LOCK_EX|LOCK_NB) returns EAGAIN. Most of the time, this kind of happens to work with the current flock-over-nfs implementation. As posix locks use the process pid in the NLM request, whereas for flock locks, we identify the holder using the task group ID. So when TGID == PID, things kind of work: - fcntl(F_SETLK) is translated into NLM call with owner == PID - Server establishes lock - flock(LOCK_EX) is translated into NLM call with owner == TGID which happens to be the same as PID - Server does nothing - procmail does its stuff - flock(LOCK_UN) is translated into NLM call with owner == TGID - Server removes lock - fcntl(F_SETLK) is translated into NLM call with owner == PID - Server does nothing, as the lock is already gone. (Note the problem during unlock - but that's not the issue here). The most obvious reason for fcntl to fail in this way that I can think of would be that procmail has magically become multithreaded, and now the PID of the thread trying to place the fcntl call is different from the TGID. Is procmail linked against libpthread in 10.2? Neil, do you remember when flock-over-NFS was added to the kernel? -- 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, or are watching someone who is.