[Mailman-Users] mailman 2.0.8 problems

[Alan L. Waller]

At 09:05 AM 2/25/2002 -0600, Thomas Hillson wrote:
>These lists vary from 10 users to 150 and there are not dead addresses as 
>they have been running for over 6 months clean, then the problem crops up 
>where the qrunner justs starts messing up. I have over 100 lists on my 
>servers and only about six that are causing problems.
>
>At 3:59 PM -0800 2/22/02, Morgan Fletcher wrote:
>>Thomas Hillson <hillson at iastate.edu> writes:
>>>  The first involves qrunner, what happens is that a list gets locked and no
>>>  mail will go through it.


I have about 600 lists with about 400,000 subscribers. I fought this same 
problem for a while until I started bumping the lock timer values in 
/var/mailman/Mailman/Defaults.py

I appeared to me that qrunner would time out before all the messages were 
delivered, however the queue is not as you expect in that the oldest should 
get sent first. Does not happen this way it looks to me that the new stuff 
was being sent and then another qrunner timeout and the old messages just 
got pushed further and further down. I had multiple qrunner sessions, 
multiple lock files, and eventually the software would just seem to 
hibernate deleted the contents of /var/mailman/locks and then it would run 
for another 12-24 hours.

This is what is working for me.... BTW my server is now steadily delivering 
14 e-mails per second average 24/7


# This variable specifies how long the lock will be retained for a specific
# operation on a mailing list.  Watch your logs/lock file and if you see a lot
# of lock breakages, you might need to bump this up.  However if you set this
# too high, a faulty script (or incorrect use of bin/withlist) can prevent the
# list from being used until the lifetime expires.  This is probably one of
# the most crucial tuning variables in the system.
LIST_LOCK_LIFETIME = hours(15)


# This variable specifies how long an attempt will be made to acquire a list
# lock by the qrunner process.  If the lock acquisition times out, the message
# will be re-queued for later delivery.
LIST_LOCK_TIMEOUT = seconds(15)


# cron/qrunner lock lifetime.  This is probably the second most crucial tuning
# variable in the system.  See the notes for LIST_LOCK_LIFETIME above.  Watch
# your logs/smtp file and make sure that QRUNNER_LOCK_LIFETIME is set longer
# than the longest period you see here.  It is a bad thing if multiple
# qrunners run at the same time.
QRUNNER_LOCK_LIFETIME = hours(48)


# Two other qrunner resource management variables.  The first controls the
# maximum lifetime of any single qrunner process, and the second controls the
# maximum number of messages a single qrunner process will, er, process.
# Exceeding either limit causes qrunner to exit, reclaiming system resources
# and deleting the lock.  Other qrunners will then process the remaining
# messages.  Set either to None to inhibit this resource check.
QRUNNER_PROCESS_LIFETIME = hours(4)
QRUNNER_MAX_MESSAGES = 150000

YMMV,

Al