The SPARC Solaris 10 OpenCSW 3.x builder fails with

======================================================================
FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/test_socket.py", line 4101, in test_create_connection
    self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
AssertionError: 128 != 146

Here 128 is ENETUNREACH

I think the issue here is that socket.create_connection iterates over the result of socket.getaddrinfo('localhost', port, 0, SOCK_STREAM) which returns [(2, 2, 0, '', ('127.0.0.1', 0)), (26, 2, 0, '', ('::1', 0, 0, 0))] on this host.

The first result is tried and returns ECONNREFUSED but then the second address is tried and this returns ENETUNREACH because this host has not IPv6 network configured.  And create_connection() raises the last exception it received.

If getaddrinfo() is called with the AI_ADDRCONFIG flag then it will only return the IPv4 version of localhost.

But if getaddrinfo returns an IPv6 address, shouldn't a localhost connection on that address work?  It seems to me that a localhost connection failing when an IPv6 localhost address is returned is an OS configuration bug.

It was my understanding that this is what the AI_ADDRCONFIG flag is
for, if you don't use it you have no such guarantee.

That sounds reasonable.  However, on my box that has an IPv6 address configured on lo, I get the same result with or without that flag:

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:48000 errors:0 dropped:0 overruns:0 frame:0
          TX packets:48000 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3991442 (3.8 MiB)  TX bytes:3991442 (3.8 MiB)
 
Python 2.7.3 (default, Jun 19 2012, 16:12:47) 
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0)
[(2, 1, 6, '', ('127.0.0.1', 80))]
>>> socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0, socket.AI_ADDRCONFIG)
[(2, 1, 6, '', ('127.0.0.1', 80))]

I think this is influenced by what  you have in /etc/hosts.  On my
laptop I also have IPv6 loopback as well as an IPv6 link-local on
eth0.  But I have both 127.0.0.1 and ::1 in /etc/hosts as locahost.
With that configuration I get the same getaddrinfo results as on the
solaris host (which btw, has the same /etc/hosts configuration for
localhost, i.e. both IPv4 & IPv6).  Basically I don't think loopback
and link-local addresses count as "configured address" for
getaddrinfo.

Btw, removing the "::1 localhost" line from /etc/hosts on the solaris
host does fix the issue and gives the same results you show.  But I
don't think this is correct.  My linux laptop behaves exactly the same
as the solaris host here.

I was about to say that I agree that AI_ADDRCONFIG should be used in create_connection. However, RFC 3493 deviates from RFC 2553 by stating

"""If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
   returned only if an IPv4 address is configured on the local system,
   and IPv6 addresses shall be returned only if an IPv6 address is
   configured on the local system.  The loopback address is not
   considered for this case as valid as a configured address.
"""

If this is taken literally, then it would not be possible to connect anymore to localhost if you have no IP address configured except for the loopback addresses - which in turn would make the test fail also (and would clearly be undesirable).

OSX clearly ignores that RFC - even with no IPv4 address configured, I get a result that includes 127.0.0.1. I wonder how other systems respond to 

socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0, socket.AI_ADDRCONFIG)

if all interfaces except for lo are down (remember to reactivate the interfaces before posting a response to the bug tracker :-)

Any patch needs to be careful to use the flag only if available. Microsoft points out that the flag works only on Vista+. Not sure whether it just has no effect on XP, or makes the call fail.

Hmm.  I wonder what is different on my (linux) box.  I have ::1 in /etc/hosts for localhost.

Regardless, it certainly wouldn't hurt to add the flag to the test.

David: I get the same on Linux as you, however, in the standard Debian installation, ::1 is *not* an address for "localhost", only for "ip6-localhost" and "ip6-loopback". Likewise, on Redhat, it seems that only "localhost6" gives you ::1. What Linux distribution are you using?

I see our previous messages crossed, I'm glad you investigated this more throughly than I did, since clearly just adding the flag could break things.

I'm using gentoo linux (gentoo stable on that particular machine).  I don't guarantee my /etc/hosts file is stock gentoo, but I think it is other than adding my host name to the localhost lines.

> I wonder how other systems respond to [...]
> if all interfaces except for lo are down

On Mageia Linux 1:

>>> socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0, socket.AI_ADDRCONFIG)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.gaierror: [Errno -5] No address associated with hostname

Antoine: thanks for the report. I fear that this rules out using AI_ADDRCONFIG: IETF has managed to break it. This is really silly.

So I'm tempted to close this as "won't fix". Comments? Build slaves would be required that a regular lookup of localhost matches the configured loopback addresses (which I feel is a reasonable operational requirement anyway).

Floris: another work around is to configure ::1 in your zone.

I have no issue with changing the buildhost's zone configuration if that's
the right thing to do. Just one more option. Is widening the expected errno
in the test a valid thing to do?

Incase it helps at all, I'm seeing the test failure preparing for adding python33 to the FreeBSD ports tree. 

On FreeBSD 9.0-RELEASE-p3 (amd64), with /etc/hosts configured as follows:

::1                     localhost.domain localhost
127.0.0.1               localhost.domain localhost

The following is returned:

>>> socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0, socket.AI_ADDRCONFIG)
[(2, 1, 6, '', ('127.0.0.1', 80)), (28, 1, 6, '', ('::1', 80, 0, 0))]
>>>

I'm guessing that this would have been resolved some time ago, am I correct?

> I'm guessing that this would have been resolved some time ago, am I correct?

You should not guess but check last builds of "SPARC Solaris 10 OpenCSW 3.x" to see if the issue stil occurs.

http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstable

By following the link I finally get to see "No current builds. Pending Build Requests: (Apr 30 15:07:05, waiting 1445 hrs, 32 mins, 26 secs)".  Is there any way that I can tell from the display whether or not the failures are related to this issue?

Oops, I've kicked the bruynooghe-solaris-csw buildslave and it should now be building again.  A bit disappointed that buildbot/twisted doesn't reconnect automatically though.

buildbot does normally reconnect automatically, so something must be wrong somewhere if it didn't.  I do seem to remember a bug that caused the slave to occasionally get confused about its current status in certain unusual circumstances...perhaps that bug has not been fixed yet.