On 07/20/2018 01:11 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Tom, please see if adding this at the top of the failing script fixes it:
>> use IO::Socket::SSL qw (inet);
>
> No, that doesn't work at all, but
>
> use IO::Socket::SSL qw (inet4);
>
> does fix it. Not sure how far that helps though --- we'd not want to put
> that in the buildfarm client would we?
maybe a more general option to "force ipv4 or ipv6" akin to what most
unix networking related utilities support with -4 and -6 might be useful?
On the other side I wonder whether passing in "MultiHomed" to the
IO::Socket::INET6 Constructor behind LWPs back might work - though the
docs are pretty light on any details on its actual behaviour:
https://metacpan.org/pod/release/SHLOMIF/IO-Socket-INET6-2.72/lib/IO/Socket/INET6.pm#CONSTRUCTOR
>
> Some more detail: tracing shows that IO::Socket::INET6 is getting used,
> and that contains code that purports to make the correct decision between
> IPv6 and IPv4, but it's going wrong. It looks like what it *actually*
> does is make sure that both the local and remote addresses can be resolved
> in the same address family. I think that the local address is probably
> "localhost", which RHEL6 will helpfully resolve as either 127.0.0.1 or ::1
> regardless of whether there's any other support for IPv6 anyplace,
> allowing INET6 to predict that the connection will work ... which it
> doesn't, but the code doesn't want to retry after failing that step.
>
> Perhaps I could fix this by rejiggering things so that localhost only
> resolves as 127.0.0.1, but I don't really want to muck with that.
> Removing the perl-IO-Socket-INET6 package would be less invasive.
yeah the removal seems easier but do you actually know yet why the
system started behaving differently in that regard?
Stefan
