Can't use localhost in Dial (Go v1.5)

[jimtsao]

Replacing with 127.0.0.1 resolves this.

[ryanfaerman]

👍 I've experienced the same issue and discovered the same solution too!

[niemeyer]

Thanks for the notice. Will have a look.

[alexcesaro]

I have the same bug on a Docker container running Ubuntu 12.04. What's curious is that it works fine when I create an SSH tunnel to a remote Mongo instance.

[kgdev]

+1

[alexcesaro]

I looked a little into this bug:
With Go 1.5: SYNC Address localhost:27017 resolved as [::1]:27017
With Go 1.4: SYNC Address localhost:27017 resolved as 127.0.0.1:27017

Since MongoDB disables ipv6 support by default the connection fails with Go 1.5.

resolveAddr in cluster.go should be updated to return IPv4 addresses first.

Should I do a PR?

[niemeyer]

If you can do that in the next couple of hours, that would be welcome. Otherwise I will have to look into it.

For background on that unusual resolver, Go doesn't support timeouts on address resolution, so that's an attempt to workaround it. More details in that upstream issue:

golang/go#6340

[alexcesaro]

I don't see any easy fix.

I would change the dial to be udp4 in resolveAddr and add an IPv6 bool to DialInfo to do a udp or udp6 dial when it is true.

It would only break for users that enabled ipv6 in Mongo and use an IPv6 address in the net.bindIp setting. But I guess there are not many (if any?) users in this case.

[niemeyer]

I'll just move into resolving IPv4 only for now.. this will unblock the vast majority of people, until we find the best solution.

[alexcesaro]

👍

[bz2]

This change breaks the juju/testing test suite:

github.com/juju/testing$ go test ./...

----------------------------------------------------------------------
FAIL: mgo_test.go:78: mgoSuite.TestStartIPv6

[LOG] 0:00.000 TRACE juju.testing mongod:48632: Tue Sep  1 14:19:47.154 [conn4] end connection 127.0.0.1:35839 (1 connection now open)
[LOG] 0:00.000 TRACE juju.testing mongod:48632: Tue Sep  1 14:19:47.154 [initandlisten] connection accepted from 127.0.0.1:35843 #8 (2 connections now open)
[LOG] 0:00.000 TRACE juju.testing mongod:48632: Tue Sep  1 14:19:47.154 [conn7] end connection 127.0.0.1:35842 (1 connection now open)
[LOG] 0:05.002 TRACE juju.testing mongod:48632: Tue Sep  1 14:19:52.155 [initandlisten] connection accepted from 127.0.0.1:35844 #9 (2 connections now open)
mgo_test.go:82:
    c.Assert(err, gc.IsNil)
... value *errors.errorString = &errors.errorString{s:"no reachable servers"} ("no reachable servers")

[LOG] 1:00.542 TRACE juju.testing mongod:48632: Tue Sep  1 14:20:47.696 [initandlisten] connection accepted from 127.0.0.1:35845 #10 (3 connections now open)
[LOG] 1:00.544 INFO juju.testing reset successfully reset admin password
OOPS: 54 passed, 2 skipped, 11 expected failures, 1 FAILED
--- FAIL: Test (60.69 seconds)

[niemeyer]

Sorry about that. The proper fix is coming. Will try to land something today or tomorrow.

[niemeyer]

For the record, another step towards proper IPv6 support is in, and got feedback from @bz2 that it fixed juju's breakage.

[tomponline]

This commit broke the mgo driver for our uses, we use IPv6 with named hosts using AAAA records for IPv6 addresses. Since commit d650c4e we have been unable to use the mgo driver and have had to roll back to before that commit.

Would it be possible to restore that commit, and add a special case for "locahost" hostnames instead?

[niemeyer]

Sorry for the trouble. It was well known that this particular configuration would break, and I generally don't do such partial fixes, but this is a special case as we had several developers complaining of the breakage with Go 1.5, so we had to take action quickly and that was the short term alternative.

We cannot special case localhost because this is just a symptom, not the actual issue. The real problem is that the resolution behavior has changed in 1.5, and thus I did a fix to bring back the correctness of IPv4 resolution, which is by far the most used, and then started to bring back the correctness of IPv6 resolution. The first step was already done: if you use an IPv6 literal address, it should work fine. I will now fix actual resolution and ping you so you have a chance to test it before it goes live, if that's okay?

Let's please move this conversation into the ticket #162 which you opened, as it's more specific to that problem.

[dhrp]

I'd like to mention that a similar issue is causing trouble when running go in Docker containers. Since Docker 1.11, Docker no longer writes the host names of linked containers into the /etc/hosts file, but relies on programs to use it's internal DNS server.

MGO, when asked to connect to a host like: mgo.Dial("mongodb://mongo:27017"), (note that it's not FQDN) fails, while connecting to an IP works. See discussion here.