![](https://secure.gravatar.com/avatar/d10cad24a9804753ca20a8ad2d2cc593.jpg?s=120&d=mm&r=g)
One of the changes I have to make for my server is to increase the lock lifetime. I suspect that other people who don't have a speedy server either, might get the same problems as me... so maybe it should be mentioned in the install docs and/or moved to a global variable in mm_cfg.py... Below is an excerpt of a message from Thomas who fixed this for me.... For my server I've changed this to 300.
"... In any case, you can easily try it out; in Mailman/MailList.py, on or around line 282, there should be a 'lifetime = 60', inside the constructor for the maillists' lockfile. Changing the '60' in, say, '600', should give you better mileage, at least until your machine gets so heavily loaded that a simple admin request takes ten full minutes to process ;) "
Ricardo.
--
![](https://secure.gravatar.com/avatar/ab1c33fc0fd591a0ea174155233a6a51.jpg?s=120&d=mm&r=g)
"RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
RK> "... In any case, you can easily try it out; in
RK> Mailman/MailList.py, on or around line 282, there should be a
RK> 'lifetime = 60', inside the constructor for the maillists'
RK> lockfile. Changing the '60' in, say, '600', should give you
RK> better mileage, at least until your machine gets so heavily
RK> loaded that a simple admin request takes ten full minutes to
RK> process ;) "
One other gotcha, if you use bin/withlist to open a locked list and then exit the interpreter without doing an explicit m.Unlock(), you're list will be locked out for the duration.
Still, I'm willing to put something in Defaults.py like this:
# How long is the default lifetime for the MailList object lock, in seconds? LIST_LOCK_LIFETIME = 120
and then set lifetime at line 282 to use this variable.
Will that work for you? -Barry
![](https://secure.gravatar.com/avatar/d10cad24a9804753ca20a8ad2d2cc593.jpg?s=120&d=mm&r=g)
Hi,
On Wed, Mar 22, 2000 at 02:06:12PM -0500, Barry A. Warsaw wrote:
One other gotcha, if you use bin/withlist to open a locked list and then exit the interpreter without doing an explicit m.Unlock(), you're list will be locked out for the duration. well I haven't used bin/withlist before, but maybe it could issue a warning when it runs?
Still, I'm willing to put something in Defaults.py like this: # How long is the default lifetime for the MailList object lock, in seconds? LIST_LOCK_LIFETIME = 120 and then set lifetime at line 282 to use this variable. Will that work for you? that would be great... thanks :)
Ricardo.
--
![](https://secure.gravatar.com/avatar/ab1c33fc0fd591a0ea174155233a6a51.jpg?s=120&d=mm&r=g)
"RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
RK> well I haven't used bin/withlist before, but maybe it could
RK> issue a warning when it runs?
Actually, I just remembered sys.exitfunc! I can set that up to unlock a locked list automatically at interpreter exit. I don't want it to implicitly save the list though -- you'll still have to do that manually if you fiddle with it from the interpreter prompt.
Note that this function doesn't run if the interpreter exits because of a signal or os._exit() call.
-Barry
![](https://secure.gravatar.com/avatar/fd4bd17264b01a28529e408abc3c7156.jpg?s=120&d=mm&r=g)
On Wed, Mar 22, 2000 at 02:06:12PM -0500, Barry A. Warsaw wrote:
RK> "... In any case, you can easily try it out; in RK> Mailman/MailList.py, on or around line 282, there should be a RK> 'lifetime = 60', inside the constructor for the maillists' RK> lockfile. Changing the '60' in, say, '600', should give you RK> better mileage, at least until your machine gets so heavily RK> loaded that a simple admin request takes ten full minutes to RK> process ;) "
One other gotcha, if you use bin/withlist to open a locked list and then exit the interpreter without doing an explicit m.Unlock(), you're list will be locked out for the duration.
Not only if you use that tool, but if you use any tool or script that doesn't clean up after itself ;) Granted, using bin/withlist it's a lot easier, but I think a note on upsides/downsides in either the FAQ or next to the timeout setting would be appropriate. 'set too low, a slow machine might give timeout erors, but set too high, a faulty script can prevent the list from being used for that long.'
(But then, i'm all for longer explanations in the FAQ and the online help, i just haven't got the time to write them, yet ;) While i'm on that subject, by the way, what are other peoples' thoughts on this issue ? Should there be more helpfiles and/or online help ? :)
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
participants (4)
-
Barry A. Warsaw
-
bwarsaw@cnri.reston.va.us
-
Ricardo Kustner
-
Thomas Wouters