Issue15617
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.
Created on 2012-08-10 13:00 by flub, last changed 2022-04-11 14:57 by admin.
Messages (18) | |||
---|---|---|---|
msg167867 - (view) | Author: Floris Bruynooghe (flub) | Date: 2012-08-10 13:00 | |
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. |
|||
msg167868 - (view) | Author: R. David Murray (r.david.murray) * ![]() |
Date: 2012-08-10 13:27 | |
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. |
|||
msg167869 - (view) | Author: Floris Bruynooghe (flub) | Date: 2012-08-10 13:29 | |
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. |
|||
msg167870 - (view) | Author: R. David Murray (r.david.murray) * ![]() |
Date: 2012-08-10 13:53 | |
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))] |
|||
msg167871 - (view) | Author: Floris Bruynooghe (flub) | Date: 2012-08-10 14:08 | |
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. |
|||
msg167872 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2012-08-10 14:39 | |
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. |
|||
msg167873 - (view) | Author: R. David Murray (r.david.murray) * ![]() |
Date: 2012-08-10 14:45 | |
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. |
|||
msg167879 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2012-08-10 15:36 | |
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? |
|||
msg167882 - (view) | Author: R. David Murray (r.david.murray) * ![]() |
Date: 2012-08-10 15:58 | |
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. |
|||
msg167971 - (view) | Author: Antoine Pitrou (pitrou) * ![]() |
Date: 2012-08-11 15:09 | |
> 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 |
|||
msg167979 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2012-08-11 16:54 | |
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. |
|||
msg168046 - (view) | Author: Floris Bruynooghe (flub) | Date: 2012-08-12 15:20 | |
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? |
|||
msg171881 - (view) | Author: Kubilay Kocak (koobs) ![]() |
Date: 2012-10-03 13:04 | |
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))] >>> |
|||
msg221884 - (view) | Author: Mark Lawrence (BreamoreBoy) * | Date: 2014-06-29 19:16 | |
I'm guessing that this would have been resolved some time ago, am I correct? |
|||
msg221895 - (view) | Author: STINNER Victor (vstinner) * ![]() |
Date: 2014-06-29 20:14 | |
> 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 |
|||
msg221900 - (view) | Author: Mark Lawrence (BreamoreBoy) * | Date: 2014-06-29 20:43 | |
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? |
|||
msg223329 - (view) | Author: Floris Bruynooghe (flub) | Date: 2014-07-17 11:43 | |
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. |
|||
msg223337 - (view) | Author: R. David Murray (r.david.murray) * ![]() |
Date: 2014-07-17 14:22 | |
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. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:57:34 | admin | set | github: 59822 |
2019-04-26 19:54:21 | BreamoreBoy | set | nosy:
- BreamoreBoy |
2014-07-17 14:22:18 | r.david.murray | set | messages: + msg223337 |
2014-07-17 11:43:55 | flub | set | messages: + msg223329 |
2014-06-29 20:43:20 | BreamoreBoy | set | messages: + msg221900 |
2014-06-29 20:14:14 | vstinner | set | messages: + msg221895 |
2014-06-29 19:16:43 | BreamoreBoy | set | nosy:
+ BreamoreBoy messages: + msg221884 versions: + Python 3.4, Python 3.5, - Python 3.3 |
2012-10-03 13:04:51 | koobs | set | nosy:
+ koobs messages: + msg171881 |
2012-08-12 15:20:01 | flub | set | messages: + msg168046 |
2012-08-11 16:54:06 | loewis | set | messages: + msg167979 |
2012-08-11 15:09:36 | pitrou | set | nosy:
+ pitrou messages: + msg167971 |
2012-08-10 15:58:44 | r.david.murray | set | messages: + msg167882 |
2012-08-10 15:36:34 | loewis | set | messages: + msg167879 |
2012-08-10 14:45:26 | r.david.murray | set | messages: + msg167873 |
2012-08-10 14:39:35 | loewis | set | nosy:
+ loewis messages: + msg167872 |
2012-08-10 14:14:12 | vstinner | set | nosy:
+ vstinner |
2012-08-10 14:08:46 | flub | set | messages: + msg167871 |
2012-08-10 13:53:28 | r.david.murray | set | messages: + msg167870 |
2012-08-10 13:29:23 | flub | set | messages: + msg167869 |
2012-08-10 13:27:00 | r.david.murray | set | nosy:
+ r.david.murray messages: + msg167868 |
2012-08-10 13:00:51 | flub | create |