Rich West wrote: >I did some further analysis and discovered that the messages (with the >same message ID) were showing up in the "ps" output as processing "from >queue". Digging a little further, I tried killing off the sendmail >processes that were processing those requests, and I saw the following >appear in the mailman log: >Sep 12 20:53:28 2005 (24387) Low level smtp error: (4, 'Interrupted >system call'), msgid: <[EMAIL PROTECTED]>
This could be normal if SMTP_MAX_SESSIONS_PER_CONNECTION = 0 since in this case, Mailman (SMTPDirect) will never close the connection from its side. However, the specific error message comes out of the bulkdeliver() method which indicates Mailman is still involved in an SMTP transaction. I.e., it is probably waiting for a response from sendmail. >So.. that got me thinking that Mailman was somehow not ending the >connection properly OR that my sendmail install really didn't like >handling multiple messages in one stream (I'm blanking as to why). Or sendmail wasn't responding to the completion of the DATA command, or ... >With >all of that in mind, I set : >SMTP_MAX_SESSIONS_PER_CONNECTION = 1 >MAX_DELIVERY_THREADS = 0 >SMTP_MAX_RCPTS = 1 > >And things started working. Odd.. Not so odd yet, I think. >Now, I know that this is definitely NOT ideal or optimal.. But, what >could be going wrong? I tried reducing the >SMTP_MAX_SESSIONS_PER_CONNECTION to "0" for my tests, and the problem >crept back. Now I think it's odd, but what happens in this case right after 'mailmanctl restart'? Does it work for the first few mails and then the problem comes back. If so, it could be that the problem only occurs after a few transactions on an open connection. >I moved that back to 1, then set SMTP_MAX_RCPTS to "0", and >the problem crept back. Only the config above seemed to work.. Now this I too find puzzling. >My mind is a jumbled mess thinking about this, but if anyone has any >ideas.. I'm all ears. :) Setting SMTP_MAX_SESSIONS_PER_CONNECTION = 1 is not particularly costly. It just means Mailman closes the SMTP connection after each transaction and reopens it for the next transaction. This is not too costly. Setting MAX_DELIVERY_THREADS which appeared in 2.0 beta 3 appears to be ignored in current versions. There are no references to it outside of Defaults.py Setting SMTP_MAX_RCPTS = 1 may impact performance, but maybe not as much as one would think. This list (mailman-users) uses personalized delivery which amounts to the same thing (at least for regular as opposed to digest deliveries). If you need SMTP_MAX_RCPTS = 1, then you've paid the price and you can VERP all deliveries (for better bounce processing) and personalize your lists for essentially no extra charge. -- Mark Sapiro <[EMAIL PROTECTED]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org 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