This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients r.david.murray, vinay.sajip
Date 2012-03-15.04:59:34
SpamBayes Score 8.88178e-16
Marked as misclassified No
Message-id <>
I'm working on a patch that updates smtpd, and when I ran the full test suite I got a hang in test_logging.  This means there's a bug in my update, but there is also a bug in the logging test.

But see below for another issue I noticed while investigating this, that is the real focus of this report.

This traceback occurs before the test hang:

test_basic (test.test_logging.SMTPHandlerTest) ... error: uncaptured python exception, closing channel <test.test_logging.TestSMTPChannel connected at 0xb5773884> (<class 'AttributeError'>:TestSMTPChannel inst)
Traceback (most recent call last):
  File "/home/rdmurray/python/p33/Lib/logging/", line 935, in emit
    smtp.sendmail(self.fromaddr, self.toaddrs, msg)
  File "/home/rdmurray/python/p33/Lib/", line 741, in sendmail
  File "/home/rdmurray/python/p33/Lib/", line 550, in ehlo_or_helo_if_needed
    if not (200 <= self.ehlo()[0] <= 299):
  File "/home/rdmurray/python/p33/Lib/", line 417, in ehlo
    (code, msg) = self.getreply()
  File "/home/rdmurray/python/p33/Lib/", line 372, in getreply
    raise SMTPServerDisconnected("Connection unexpectedly closed")
smtplib.SMTPServerDisconnected: Connection unexpectedly closed
Logged from file , line 0

I think the event.wait() in the test should have a timeout; setting it to, say, 5 lets the tests complete (with a failure) in this situation.

Now the real issue:

Looking at the smtp handler code, I notice that unlike the socket handler it doesn't provide any way to set the timeout.  This means it could potentially hang forever trying to log an event, which while not related to the above issue is something that I think should be fixed.

I've marked this as behavior, since the SMTP connection should probably get a reasonable default timeout even in bug fix releases, but in 3.3 you'll probably want to make it settable and perhaps shorten the default relative to what you use for the maint releases.
Date User Action Args
2012-03-15 04:59:35r.david.murraysetrecipients: + r.david.murray, vinay.sajip
2012-03-15 04:59:35r.david.murraysetmessageid: <>
2012-03-15 04:59:35r.david.murraylinkissue14314 messages
2012-03-15 04:59:34r.david.murraycreate