[issue18792] test_ftplib timeouts

[Gregory P. Smith]

Gregory P. Smith added the comment:

https://bugs.python.org/issue29639 opened to track undoing this when 
appropriate.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Gregory P. Smith]

Gregory P. Smith added the comment:

FYI - hardcoding these addresses is now causing me problems as I try to get our 
test suite passing on IPv6 only hosts.  "localhost" is correct.  

IMNSHO if for some reason a system cannot resolve "localhost" into a correct 
address, it should be banned from running any form of networking related test. 
:/

I should not have to write messy conditional code to try and determine which 
type of socket I will likely need to bind to to determine which format of IP 
address string I need to supply as the localhost bind address.  That is 
backwards!

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Charles-François Natali]

Charles-François Natali added the comment:

 Some ftplib tests sometimes time out. Seem they seem to try to connect to 
 localhost (rather than 127.0.0.1), I was wondering if this could be a DNS 
 issue and if we should resolve localhost in advance like Charles-François 
 did for some other tests (or simply hardcode 127.0.0.1, actually).

If it only happens on Windows = 7 buildbots, then it's likely a
consequence of this:
http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why

Apparently, since Windows 7, localhost doesn't appear in the hosts
file anymore: so, depending on your DNS resolver settings, this could
perfectly explain such timeouts (assuming it's not a firewall issue).

Hard-cording 127.0.0.1 for this test should be OK, because the server
setup explicitly binds an AF_INET socket. We'll probably have to check
the rest of the test suite for similar issues.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Antoine Pitrou]

Antoine Pitrou added the comment:

 Hard-cording 127.0.0.1 for this test should be OK, because the server
 setup explicitly binds an AF_INET socket. We'll probably have to check
 the rest of the test suite for similar issues.

Ok, let's do it!

--
keywords: +easy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Antoine Pitrou]

Antoine Pitrou added the comment:

Here is a patch for default.

--
keywords: +patch
Added file: http://bugs.python.org/file31395/support_host.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Charles-François Natali]

Charles-François Natali added the comment:

Changing support.HOST from 'localhost' to '127.0.0.1' means that on dual-stack
hosts (I don't think the test suite would run on IPv6-only hosts anyway), the
tests will now always use IPv4, whereas they are currently using either IPv6 or
IPv4 addresses depending on the host's name resolution settings.
For example, on a RHEL6 box:

 socket.getaddrinfo('localhost', 0)
[(10, 1, 6, '', ('::1', 0, 0, 0)), (10, 2, 17, '', ('::1', 0, 0, 0)),
(10, 3, 0, '', ('::1', 0, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 0)), (2,
2, 17, '', ('127.0.0.1', 0)), (2, 3, 0, '', ('127.0.0.1', 0))]

So on this host, 'localhost' resolves to '::1'. I think it would be
better to have support.HOST set to socket.getaddrinfo('localhost', 0)[0][4][0]
(sic), so that the test will use the preferred protocol on the target host, and
also that IPv6 is also tested in tests which don't explicitely use
'::1'. But this
means that we should have an support.HOSTv4 for tests that explicitly rely on
IPv4, e.g.  test_ftplib.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Antoine Pitrou]

Antoine Pitrou added the comment:

 Changing support.HOST from 'localhost' to '127.0.0.1' means that on
 dual-stack
 hosts (I don't think the test suite would run on IPv6-only hosts
 anyway), the
 tests will now always use IPv4, whereas they are currently using
 either IPv6 or
 IPv4 addresses depending on the host's name resolution settings.

That would only be true if the server we are contacting happens to
listen on both IPv6 and IPv4, right? I don't think we have such a
situation in the test suite. Clients can use create_connection()
for transparent support of IPv6 and IPv4, but servers have to choose
a family when creating their socket.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Charles-François Natali]

Charles-François Natali added the comment:

 That would only be true if the server we are contacting happens to
 listen on both IPv6 and IPv4, right? I don't think we have such a
 situation in the test suite.

Ah, I thought some code was using getaddrinfo() to select an arbitrary
bind() address for localhost.

That's OK then.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Charles-François Natali]

Charles-François Natali added the comment:

LGTM

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Roundup Robot]

Roundup Robot added the comment:

New changeset 085ba7d85eb2 by Antoine Pitrou in branch 'default':
Issue #18792: Use 127.0.0.1 or ::1 instead of localhost as much as 
possible, since localhost goes through a DNS lookup under recent Windows 
versions.
http://hg.python.org/cpython/rev/085ba7d85eb2

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7728b073c77c by Antoine Pitrou in branch '3.3':
Issue #18792: Use 127.0.0.1 or ::1 instead of localhost as much as 
possible, since localhost goes through a DNS lookup under recent Windows 
versions.
http://hg.python.org/cpython/rev/7728b073c77c

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Roundup Robot]

Roundup Robot added the comment:

New changeset 48de8df194d9 by Antoine Pitrou in branch '2.7':
Issue #18792: Use 127.0.0.1 or ::1 instead of localhost as much as 
possible, since localhost goes through a DNS lookup under recent Windows 
versions.
http://hg.python.org/cpython/rev/48de8df194d9

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Antoine Pitrou]

Antoine Pitrou added the comment:

Done, thanks :)

--
resolution:  - fixed
stage: needs patch - committed/rejected
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18792] test_ftplib timeouts

[Antoine Pitrou]

New submission from Antoine Pitrou:

Some ftplib tests sometimes time out. Seem they seem to try to connect to 
localhost (rather than 127.0.0.1), I was wondering if this could be a DNS 
issue and if we should resolve localhost in advance like Charles-François did 
for some other tests (or simply hardcode 127.0.0.1, actually).

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7060/steps/test/logs/stdio

(example:

==
ERROR: testTimeoutDefault (test.test_ftplib.TestTimeouts)
--
Traceback (most recent call last):
  File 
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py,
 line 953, in testTimeoutDefault
ftp = ftplib.FTP(localhost)
  File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py, 
line 115, in __init__
self.connect(host)
  File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py, 
line 150, in connect
source_address=self.source_address)
  File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py, 
line 454, in create_connection
raise err
  File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py, 
line 445, in create_connection
sock.connect(sa)
socket.timeout: timed out

)

--
components: Tests
messages: 195717
nosy: giampaolo.rodola, neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ftplib timeouts
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18792
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com