[Mailman-Users] Recursion problem with "disabled" cron job.

[Lindsay Haisley]

Here's what happened. Among the lists my server hosts is one for a
local folk music mailing list. It's a large, "general announcements"
list, on a short fuse for bounces (bounce_score_threshold = 1.0). Last
weekend I noticed 49 disablement notices in my inbox, all of them from
Microsoft domain names - hotmail.com, msn.com, outlook.com, etc. It
seems that MS had blacklisted FMP's IP address, triggering bounces and
subsequent disablements.

I dealt with Microsoft and got the blacklisting removed, and we went
through the subscriber list on the web UI and re-enabled all the
disabled addresses.

This is when the recursive error started happening. It looks as if what
we did somehow got crosswise with Mailman's internal record keeping,
and something in MM's relational database setup is now corrupt.

So I can pretty definitively identify the list, based on your
discussion, and what happened here, which is causing the problem. The
question is, how can we fix it?

We know the addresses which were disabled. Would it suffice to delete
these addresses from the list and re-add them?? Is there some other way
to bring what appears to be effectively a non-normalized relational
database back in sync with itself?

On Fri, 2018-10-12 at 11:31 -0700, Mark Sapiro wrote:
> On 10/12/2018 08:20 AM, Lindsay Haisley wrote:
> > I'm running Mailman 2.1.18-1
> > I'm running cron job daily with this command:
> > 
> > /usr/bin/python -S /usr/lib64/mailman/cron/disabled
> > 
> > I've started getting the following messages indicating a code
> > problem
> > with this script, to wit:
> > 
> > Traceback (most recent call last):
> >   File "/usr/lib64/mailman/cron/disabled", line 227, in <module>
> >     main()
> >   File "/usr/lib64/mailman/cron/disabled", line 204, in main
> >     member)
> >   File "/usr/lib64/mailman/Mailman/Pending.py", line 67, in
> > pend_new
> >     db = self.__load()
> >   File "/usr/lib64/mailman/Mailman/Pending.py", line 97, in __load
> >     return cPickle.load(fp)
> >   File "/usr/lib64/mailman/Mailman/MailList.py", line 138, in
> > __getattr__
> >     return getattr(self._memberadaptor, name)
> >   File "/usr/lib64/mailman/Mailman/MailList.py", line 138, in
> > __getattr__
> >     return getattr(self._memberadaptor, name)
> >   etc .....
> > 
> > .... until the recursion limit is exceeded.
> 
> 
> At first glance, this doesn't seem related to cron/disabled.
> 
> The scenario is cron/disabled has found a list member whose delivery is
> disabled by bounce and is due another warning notice. It is getting a
> new 're-enable' token for the notice. This calls mlist.pend_new and the
> first thing that does is try to load the list's pending.pck file. How
> that gets into a loop calling the list's __getattr__() method is not
> clear, but I suspect a corrupt pending.pck file for some list.
> 
> I would do the following in bash:
> 
> cd /usr/lib64/mailman/
> for list in `bin/list_lists --bare`; do
>     if [ -f lists/$list/pending.pck ]; then
>         echo $list
>         bin/dumpdb lists/$list/pending.pck|grep evictions
>     fi
> done
> 
> This should print two lines for every list that has a pending.pck, the
> name of the list and a line that begins
> 
>     'evictions': {
> 
> You are looking for a list that doesn't print the 'evictions' line or
> that exhibits the loop.
> 
-- 
Lindsay Haisley       | "The first casualty when
FMP Computer Services |         war comes is truth."
512-259-1190          |            
http://www.fmp.com    |     -- Hiram W Johnson