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 <[EMAIL PROTECTED]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
