On Tue, Mar 07, 2006 at 11:20:10AM -0800, Shannon C. Dealy wrote: > On Tue, 7 Mar 2006, Lionel Elie Mamane wrote: >> thank you for your bug report.
>>On Mon, Mar 06, 2006 at 12:55:44PM -0800, Shannon Dealy wrote: >>> Under some circumstances, list specific stale lock files are left >>> (...) At the very least restarting mailman should cleanup these >>> stale lock files, As a mitigating measure, I can at least clean those locks early in the boot process on a reboot. (Before any httpd gets run, but after full filesystems are mounted.) >>> in particular what I assume is the master lock: listname.lock and >>> probably the actual source of my problems. A better solution >>> would probably include actually checking the lock files >>> periodically to make sure they are still valid. >> Yes. >> You may be hit by something like >> http://mail.python.org/pipermail/mailman-developers/2006-January/018506.html > Proper design of locking would normally imply the lock is > automatically released when the thread terminates unless it is > released earlier As far as I understand, the situation is: The lock is released at the Python level at process exit time - whatever the reason for the exit is (end of control flow, SIGINT/SIGTERM, ...). This happens in a general end-of-process cleanup that may be lengthy under high system load. But Apache will not wait very long for that, and will send SIGKILL to a CGI that hasn't terminated 3s after a SIGTERM. The Mailman code, in some situations, thus overrides the general cleanup to do the shorter "release lock, exit process without cleanup" on SIGTERM. I tried to understand why it is not done on a more systematic basis (and if they would take patches to make it more systematic), but got no answer from them. That ML post was about a specific instance where it is not done. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
