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 Stijn.Hoop
Recipients BreamoreBoy, Stijn.Hoop, ankitoshniwal, dfranke, loewis, mcjeff, r.david.murray
Date 2013-04-18.14:31:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
OK, dumping my current findings here, as I'm still not sure what the expected results should be.

First of all, Lib/ calls gethostbyaddr with a name. As in, gethostby _ADDR_ with a name.

This works because Modules/socketmodule.c internally uses setipaddr() to resolve the name to an address. setipaddr() does this using a call to getaddrinfo() with hints.ai_family == AF_UNSPEC and no further flags.

On my system (confirmed using the test program attached) this results in SIX entries, and this is the part that confused me.

Due to virtualization I have a virtual bridge virbr0 configured with an internal IP address, as well as my LAN-connected bridge br0 with IP address Both of these addresses are returned in the call to getaddrinfo() (each one 3 times), but NOT ALWAYS IN THE SAME ORDER.

And this is the clue as to why python's socket.getfqdn() does not behave consistently. For does not resolve to anything, hence it will return "pclin281". And will backwards resolve to as the PTR record points to that entry.

Now, again, I'm not entirely sure what to do here. I agree that this is not a simple bugfix. I also think that, apart from the weirdness of getaddrinfo() return order, socket.getfqdn() is doing it's documented job of returning /an/ FQDN for a given host.

But in case of the guaranteed LOCAL canonical hostname, another function is warranted, imho.

Does this make sense?

For the record, output of a given run on my system:

[TUE\shoop@pclin281] <~/tmp> ./test
gai canon result 0:
gai canon result 1: (null)
gai result 0: (null)
gai result 1: (null)
gai result 2: (null)
gai result 3: (null)
gai result 4: (null)
gai result 5: (null)
ghbn result 0 h_name:
ghbn result 0 h_alias: __NONE__
ghbn result 1 h_name:
ghbn result 1 h_alias: __NONE__
ghbn result 2 h_name:
ghbn result 2 h_alias: __NONE__
ghbn result 3 h_name:
ghbn result 3 h_alias: __NONE__
ghbn result 4 h_name:
ghbn result 4 h_alias: __NONE__
ghbn result 5 h_name:
ghbn result 5 h_alias: __NONE__
ghbn result 6 h_name:
ghbn result 6 h_alias: __NONE__
ghbn result 7 h_name:
ghbn result 7 h_alias: __NONE__
ghbn result 8 h_name:
ghbn result 8 h_alias: __NONE__
ghbn result 9 h_name:
ghbn result 9 h_alias: __NONE__
Date User Action Args
2013-04-18 14:31:32Stijn.Hoopsetrecipients: + Stijn.Hoop, loewis, r.david.murray, dfranke, mcjeff, BreamoreBoy, ankitoshniwal
2013-04-18 14:31:32Stijn.Hoopsetmessageid: <>
2013-04-18 14:31:32Stijn.Hooplinkissue5004 messages
2013-04-18 14:31:31Stijn.Hoopcreate