[Mailman-Users] Mailman no longer working or working very slowly

Mark Sapiro mark at msapiro.net
Wed Feb 17 15:55:46 CET 2010


Steven Jones wrote:
>
>Yesterday after 5 years of operation ou mailman application has "died" it seems to be barely running taking 3 or more hours to process lists...previous load was <0.2 now its around 1 with a python process absorbing 1 CPU constantly.


Which python process - i.e.which qrunner.

Also look in Mailmans qfiles/* directories to see which one has a large
number of messages.


>We are running on RHEL3-32bit and the errors are,
>
>============
>
>Error log for Mailman (vuwunicosmtp004.vuw.ac.nz:/var/log/mailman/error)
>
>says:
>
>
>
>RuntimeError: maximum recursion depth exceeded
>
>
>
>Feb 17 07:48:26 2010 (13368) SHUNTING: 1266281245.229378+bd3f1d42e27ad38cf532b809460a0b0a8aef00e7
>
>
>
>The last number is a message ID in Mailman queue
>
>/var/mailman/qfiles/shunt/1266281245.229378+bd3f1d42e27ad38cf532b809460a0b0a8aef00e7.pck
>============


How many of these are there? This may be unrelated. Is there a
traceback with the above error? What is it?


>We have a similar case via googling suggesting a DNS issue, however we have spent some hours checking DNS as well as the server and cant find any obvious fault.
>
>
>
>http://mail.python.org/pipermail/mailman-users/2008-November/064166.html


This probably isn't relevant. My guess (and it's only that) is you may
have a backlogged qfiles/out/ queue and the delay is in outgoing
runner. What's in Mailman's error log?

Note: In your RedHat package, Mailman's queue directory that I refer to
as qfiles/ is probably actually /var/spool/mailman/

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan



More information about the Mailman-Users mailing list