[Mailman-Developers]
[ mailman-Bugs-625516 ] Archiver ends in NotLockedError
noreply@sourceforge.net
noreply@sourceforge.net
Sat Oct 19 22:04:08 2002
Bugs item #625516, was opened at 2002-10-19 01:30
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=625516&group_id=103
Category: Pipermail
Group: 2.1 beta
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tokio Kikuchi (tkikuchi)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Archiver ends in NotLockedError
Initial Comment:
With most recent CVS version, archiver ends with
following error message in logs/error and the message
is shunted. No actual error is observed in the archived
messages.
Fixing unlock=0 to unlock=1 in Archiver/HyperArch.py as
was in rev 2.19 solved the problem. May be we should
tell the HyperArch that the mlist is locked already.
Here is the error log.
Oct 19 13:24:22 2002 (77321) Uncaught runner exception:
<LockFile 137238860: /ho
me/mailman4/locks/mm-test.lock [unlocked: 18000sec]
pid=77321>: None
Oct 19 13:24:22 2002 (77321) Traceback (most recent
call last):
File "/home/mailman4/Mailman/Queue/Runner.py", line
105, in _oneloop
self._onefile(msg, msgdata)
File "/home/mailman4/Mailman/Queue/Runner.py", line
154, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
File "/home/mailman4/Mailman/Queue/ArchRunner.py",
line 74, in _dispose
mlist.Save()
File "/home/mailman4/Mailman/MailList.py", line 490,
in Save
self.__lock.refresh()
File "/home/mailman4/Mailman/LockFile.py", line 222,
in refresh
raise NotLockedError, '%s: %s' % (repr(self),
self.__read())
NotLockedError: <LockFile 137238860:
/home/mailman4/locks/mm-test.lock [unlocked
: 18000sec] pid=77321>: None
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-10-19 17:04
Message:
Logged In: YES
user_id=12800
I think this is occurring because the archiver pickles the
MailList and the MailList pickles the lock object. When the
MailList -- and thus the lock -- is unpickled, and then
destroyed, the __del__ runs and unlocks the list out from
underneath us. This happens because you now have two
MailList objects in the same process pointing to the same
lock. That ordinarily can't happen, except in this
unpickling situation.
I think.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=625516&group_id=103