[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.