[Matt Davis]
On 18 May 2000, Harald Meland wrote:
Try again, but only after you have put
LIST_LOCK_DEBUGGING = 1
in your Mailman/mm_cfg.py, as current CVS Mailman has debug lock logging turned off by default.
Did that and got this..
[mailman@dogpound logs]$ cat locks May 18 14:46:29 2000 (9011) davis.lock laying claim May 18 14:46:29 2000 (9011) davis.lock unexpected linkcount <> 2: 1 May 18 14:46:29 2000 (9011) davis.lock lifetime has expired, breaking May 18 14:46:30 2000 (9011) davis.lock got the lock May 18 14:46:30 2000 (9011) davis.lock laying claim May 18 14:46:30 2000 (9011) davis.lock already locked [mailman@dogpound logs]$
The above strangeness was probably caused by a buglet in the current CVS LockFile.py; I believe it gets the order of unlink() calls wrong.
As I see it, it is more important for the lock file to never have a link count that is neither 0 or 2 than it is to make sure there are no tempfile turds. This implies that the real lock file should be unlink()ed before the tempfile, and not the other way around. Here's a (untested) patch (which also touches on some other issues I noticed while I was at it :):
I noticed another apparent inconsistency in LockFile.py, too: The comment at the start of __break() seems to imply that calling __touch() will totally remove the race condition, while I believe all it does is make the race condition a little less likely.
However, I don't think that neither the order of unlink calls nor any race condition is responsible for the problem you're having -- in fact, I believe everyone running current CVS Mailman will have the exact same problem. Here's another (untested) patch which tries to address the problem (these patches are not supposed to depend on the above patch, BTW):
HTH, HAND,
Harald