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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan