[Mailman-Users] bug adding user, and archiving gets "shunted"

[Mark Sapiro]

Lucio Chiappetti wrote:

>On Wed, 30 Mar 2011, Lucio Chiappetti wrote in thread starting at
>http://mail.python.org/pipermail/mailman-users/2011-March/071332.html
>
>> and ran bin/withlist -l -a -r fix_url
>
>> I still have some problems when subscribing a new user, and concerning 
>> message archiving. I will post a separate request for clarity.
>
>After I fixed the problems described in the thread quoted above, I had
>the following problems.
>
>  - when subscribing an user (myself) to the "mailman" list via the web
>    interface I get the message on the screen
>
>Bug in Mailman version 2.1.11
>We're sorry, we hit a bug!
>
>Please inform the webmaster for this site of this problem. Printing of 
>traceback and other system information has been explicitly inhibited, but 
>the webmaster can find this information in the Mailman error logs.
>
>     after a while *root* (not me as "mailman-owner" !!) receives a message
>     to visit the list control page to accept the subscription request,
>     but such page has no pending requests
>
>  - when subscribing an user (myself) to any other list via the web
>    interface I get the same "bug" message, but after a while I receive
>    the confirmation message, and if I confirm the welcome message,
>    and are subscribed
>
>  - I removed ALL lists, because "mailman" was created with newlist
>    before I ran fix_url. When I recreate it with newlist, also mailman
>    behaves as any other list i.e.
>
>     - "bug message" on the screen
>     - nevertheless confirmation e-mail
>     - and regular welcome if I confirm
>
>    what stuff in /var/lib/mailman/logs/error is relevant ?



Potentially all of it from one such error, but most problems can be
diagnosed with just the python traceback from the error. In some
cases, the web server information is helpful for errors in CGIs.


>The other question is that if I send a message to a list, the member
>receive it, but the message is NOT archived.
>
>    I see that a file appears in qfiles/shunt/


Here again, there will be an error and a python traceback associated
with the shunted message. Archiving issues are often permission
problems. Have you run Mailman's bin/check_perms? In any case, the
traceback is needed to say more.


>Note that I did not install any crontab (since my machine is just a test 
>arrangement). Are crontabs necessary for the archiver ?


No. None of the cron jobs are required for Mailman's basic operation.
There should be a crontab.in file in Mailman's cron/ directory that
has more detail as to what the individual crons do.


>Is there any FAQ or doc which describes what is in logs and qfiles, and 
>how to interpret and dispose of it ?


There's probably some, but not collected in one place :(

See the mmdsr script in the contrib/ directory for a daily log analysis
program.


>In particular how do I get rid of all old stuff there (other than doing it 
>manually), so that I'll have only errors after a fresh restart ?


There should be no "old stuff" other than logs which are normally
handled by logrotate.

On my test/development system, I have a shell script to copy /dev/null
to all the logs, but you can simply rm them as they will be
automatically created when written.

There is a cron job called cull_bad_shunt if your MM is recent enough.
See the documentation for BAD_SHUNT_* settings in Defaults.py.


>What material from logs/error or qfiles/shunt should be posted to this 
>list for diagnostics (if any) ?


Most likely nothing from qfiles/shunt. These are the messages that
couldn't be completely processed due to some exception. After the
underlying issue is fixed, you can finish processing the message by
running bin/unshunt. If you run bin/unshunt before fixing the
underlying issue, the message will be shunted again. To view the files
use bin/show_qfiles or bin/dumpdb. show_qfiles displays only the
message and accepts multiple file arguments. dumpdb only accepts a
single file, but also dumps the metadata associated with the queue
entry.

For logs/error, for a shunted message, post the python exception and
the entire traceback. For a CGI error, it's safest to post everything
with the timestamp of the error, but if there is sensitive information
in the web server or python configuration sections, it is OK to mung
it as long as the munging is obvious. You don't have to post more than
one traceback if they are the same.

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