[issue12210] test_smtplib: intermittent failures on FreeBSD

2021-05-28 Thread Irit Katriel
Irit Katriel added the comment: 2.7-only issue. -- nosy: +iritkatriel resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue12210] test_smtplib: intermittent failures on FreeBSD

2015-06-24 Thread Stefan Krah
Stefan Krah added the comment: If it is a DNS failure, the timeout of 3s indeed looks too low for me. On a misconfigured machine I'm easily getting timeouts of 20s, (not for this particular test, just in general, e.g. when using ssh). -- ___ Python

[issue12210] test_smtplib: intermittent failures on FreeBSD

2015-06-24 Thread R. David Murray
R. David Murray added the comment: It would have to be a misconfigured machine that doesn't have 'localhost' in /etc/hosts (so that a lookup of localhost goes through DNS). Or, I suppose, one that prioritizes the resolver over /etc/hosts (is that even possible?) I would think other tests

[issue12210] test_smtplib: intermittent failures on FreeBSD

2015-06-24 Thread Stefan Krah
Stefan Krah added the comment: I think it's also possible to misconfigure /etc/nsswitch.conf. When I opened this issue, my buildbot had the FreeBSD default configuration. I no longer have any FreeBSD machines, so I cannot check this now. -- ___

[issue12210] test_smtplib: intermittent failures on FreeBSD

2015-06-23 Thread R. David Murray
R. David Murray added the comment: Those are in the second (or rather the first, in the file) group of tests, which have a timeout of 3 on python3. The comment in the test case says that DNS lookup delays can cause timeouts. Is there any chance that that machine sometimes has problems

[issue12210] test_smtplib: intermittent failures on FreeBSD

2015-06-22 Thread koobs
koobs added the comment: Observed the following test_smtplib failure on koobs-freebsd10, noting that the timeout parameter is still 3 test test_smtplib failed -- Traceback (most recent call last): File /usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/test/test_smtplib.py, line 222,

[issue12210] test_smtplib: intermittent failures on FreeBSD

2013-01-17 Thread Stefan Krah
Stefan Krah added the comment: Since this occurs only on 2.7 and *very* rarely, let's close it. -- resolution: out of date - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12210

[issue12210] test_smtplib: intermittent failures on FreeBSD

2011-10-06 Thread Stefan Krah
Stefan Krah stefan-use...@bytereef.org added the comment: Naturally, as soon as I declare it fixed, it occurs again: http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%202.7/builds/326 -- status: closed - open ___ Python tracker

[issue12210] test_smtplib: intermittent failures on FreeBSD

2011-10-03 Thread Stefan Krah
Stefan Krah stefan-use...@bytereef.org added the comment: I haven't seen this in a while, so let's assume it's fixed. -- resolution: - out of date stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org

[issue12210] test_smtplib: intermittent failures on FreeBSD

2011-05-29 Thread Stefan Krah
New submission from Stefan Krah stefan-use...@bytereef.org: With Python 2.7, the FreeBSD AMD64 bot has sporadic failures in test_smtplib. Since these failures don't occur in other branches, I wonder if the timeout of 3 seconds is too low in 2.7. The timeout is 15 seconds in 3.3. test

[issue12210] test_smtplib: intermittent failures on FreeBSD

2011-05-29 Thread Stefan Krah
Stefan Krah stefan-use...@bytereef.org added the comment: Indeed, increasing the timeout to 15 solves the problem (I ran the test with the -F option for about 100 times). Since the timeout has been increased before to deal with flaky tests (52682bd738a7), I guess it's ok to do the same for 2.7.

[issue12210] test_smtplib: intermittent failures on FreeBSD

2011-05-29 Thread Stefan Krah
Stefan Krah stefan-use...@bytereef.org added the comment: Hmm, testVRFY occurs twice, once with timeout=15 and once with timeout=3. So there might be another reason why the test passes on 3.3 but not on 2.7. Anyway, increasing the timeout to 15 throughout does solve (or suppress) the problem.