[Mailman-Developers] Serious mailman locking bug
Hrvoje Niksic
hniksic@iskon.hr
21 Jul 2000 11:37:43 +0200
This seems to be new in beta4 (as opposed to beta2, which I used
previously).
When a mailing list object fails to be created, its lock persists. So
the code that attempts to do something like this fails:
try:
listobj = MailList.MailList(name)
try:
# do some stuff involving listobj
finally:
# Unlock listobj, whatever happens
listobj.Unlock()
except Errors.MMListError:
# MailList constructor failed because there is no list with
# specified name. There should be no lock at this point.
pass
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:
>>> x=MailList.MailList('no-such-list')
Traceback (innermost last):
File "<stdin>", line 1, in ?
File "/usr/lib/mailman/Mailman/MailList.py", line 75, in __init__
self.Lock()
File "/usr/lib/mailman/Mailman/MailList.py", line 1343, in Lock
self.Load()
File "/usr/lib/mailman/Mailman/MailList.py", line 892, in Load
raise Errors.MMUnknownListError
Mailman.Errors.MMUnknownListError
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
that:
>>> y=MailList.MailList('no-such-list')
... 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.