[Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list...

[Chuq Von Rospach]

On 5/1/01 1:40 PM, "Barry A. Warsaw" <barry at digicool.com> wrote:
> However, if I hit the stop button before the page is finished loading,
> I can see that the CGI process continues to run for a while and then
> it may or may not clear the locks.

That would match something I've been seeing and sorta tring to debug (except
it seems for me it only happens when I'm not watching, of course). And once
someone hits stop and reloads, they hang waiting for a lock, and so do
others -- and I can come in and check in a morning and see 50 broken locks
for a list... 

> So my next approach is to write a very minimal signal handler that
> only unlocks the list, and install this on SIGTERM.

That's work, but I suggest an alternative, or a second item: when you try to
set a lock, and one is set, see if the process that set the lock still
exists (the info is available in the locks/ dir with a bit of poking). If
that process is gone, delete the lock and move forward.

That way, both sides of the equation can fix the problem if needed.

> If you've read this far, the implication is that if the user hits the
> stop button, Mailman will in essence abort any changes to list
> configuration that this invocation may have made.

As it should, IMHO. The only caveat, I think, is that you need to look
through the code for places where breaking in the middle can leave you with
incomplete or corrupted data, and protect those pieces from breakage, and
handle the interrupt once you leave them.

If you can be sure that won't happen, great. But I'd make double-sure...