This seems to be new in beta4 (as opposed to beta2, which I used
When a mailing list object fails to be created, its lock persists. So
the code that attempts to do something like this fails:
listobj = MailList.MailList(name)
# do some stuff involving listobj
# Unlock listobj, whatever happens
# MailList constructor failed because there is no list with
# specified name. There should be no lock at this point.
Now, if the MailList constructor fails, no lock should be created.
But apparently a lock does get created and since there's no way to
unlock it from Python (I can't call Unlock() because I didn't get a
MailList object in the first place), the lock persists and blocks the
next invocation of the same code.
You can try the same interactively:
Traceback (innermost last):
File "<stdin>", line 1, in ?
File "/usr/lib/mailman/Mailman/MailList.py", line 75, in __init__
File "/usr/lib/mailman/Mailman/MailList.py", line 1343, in Lock
File "/usr/lib/mailman/Mailman/MailList.py", line 892, in Load
OK, the creation of the list object failed, and we don't have an
object to call Unlock() on. However,
/var/lib/mailman/locks/no-such-list* locks do exist, and because of
... constructor hangs, waiting for the lock to be obtained ...
This breaks my application that tries to check things about lists that
may or may not exist. I think this worked OK in 2.0beta2.
I'd very much appreciate any help.