[Mailman-Users] Strange errors

[Mark Sapiro]

Dan Szkola wrote (in separate posts):
>
>Is there somewhere I can enable more debugging to help get to the bottom of
>this issue? I'm finding next to nothing in the logs that is helpful.


As Brad replied, there are no debugging switches, but I'm not sure that
this would be helpful in this case anyway. The traceback you get in
sendmail's DSN tells us what happens, and the why doesn't seem to be
Mailman. Also, the error occurs in the import of the logging module so
there is a catch 22 in trying to log information about the error.

Next time this occurs, you could look to see if Python's traceback.py
is actually in the library. Normally, there will be a traceback.py,
traceback.pyc and traceback.pyo in /usr/lib/python2.4, but only the
traceback.py should be necessary. The others are compiled versions
that will be (re)created as needed.


>I restarted only the mailman processes using bin/mailmanctl restart and 
>post still
>generate the error above.


This is further confirmation that the problem isn't Mailman per se. The
only thing I can think is that somehow something that affects Python
is being set by sendmail in the environment that it passes to the
wrapper, and that this only happens after a number of posts.
Environment variables that affect Python should begin with 'PYTHON'
and are described on the python man page.

You could try the following patch to the $prefix/scripts/post script to
print the environment each time it is invoked. Assuming sendmail
doesn't choke on this in the normal case, it should appear in the DSN
in the error case.

Patch---------------------------------------------
--- scripts/post        2005-10-14 16:31:41.937500000 -0700
+++ scripts/post_patched        2005-10-18 12:14:18.031250000 -0700
@@ -27,6 +27,9 @@
 """

 import sys
+from os import environ
+for env_var in environ:
+    print env_var, environ[env_var]

 import paths
 from Mailman import mm_cfg
End Patch---------------------------------------------

Perhaps a better plan would be to patch the $prefix/scripts/admin
script instead (same patch). Presumably mail to the listname-admin
address will bounce the same way when the problem occurs because it
begins with the same imports, but listname-admin is a deprecated name
and shouldn't be receiving mail normally, so patching the admin script
and sending mail to listname-admin should get the information you want
in the DSN without possibly choking sendmail in the 'normal' case.

>I will put the line below into the mm_cfg.py 
>file and
>restart sendmail and watch what happens.
>
>>I have no reason other than superstition for the following suggestion,
>>but try
>>
>>SMTP_MAX_SESSIONS_PER_CONNECTION = 1
>>
>>in mm_cfg.py and see if that helps. This will cause Mailman to close
>>the SMTP connection to sendmail after each transaction. This might
>>avoid the problem, but since I have no idea what the problem is, I
>>have no idea if this will help.


OK. Let us know.

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