You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
go test -v -run=TestUpdateResolvConf
=== RUN TestUpdateResolvConf
--- FAIL: TestUpdateResolvConf (0.39s)
dnsclient_unix_test.go:208: lookup golang.org on 192.168.0.1:53: server misbehaving
dnsclient_unix_test.go:208: lookup golang.org on 192.168.0.1:53: server misbehaving
dnsclient_unix_test.go:208: lookup golang.org on 192.168.0.1:53: server misbehaving
dnsclient_unix_test.go:208: lookup golang.org on 192.168.0.1:53: server misbehaving
dnsclient_unix_test.go:221: #0: got [192.168.0.1]; want [8.8.8.8]
dnsclient_unix_test.go:208: lookup www.example.com on 192.168.0.1:53: server misbehaving
dnsclient_unix_test.go:208: lookup www.example.com on 192.168.0.1:53: server misbehaving
dnsclient_unix_test.go:221: #2: got [192.168.0.1]; want [8.8.4.4]
FAIL
mikioh
changed the title
net: TestUpdateResolvConf fails since 5efbdd9d10908206d4e0351cb4724c5fefdfa2be
net: TestUpdateResolvConf fails since https://github.com/golang/go/commit/5efbdd9d10908206d4e0351cb4724c5fefdfa2be
Feb 21, 2016
The problem as far as I can tell it is TestUpdateResolvConf uses resolvConfTest to write and load a /tmp/foo/resolv.conf file like "nameserver 8.8.8.8\n". However, the actual DNS resolver code still checks /etc/resolv.conf.
The logic in forceUpdate intentionally zeros out lastChecked (which only limits os.Stat calls), but previously it left conf.mtime untouched. So the next DNS client call would call os.Stat("/etc/resolv.conf") and see it (most likely) still matches conf.mtime.
However, now that conf.mtime has been moved to conf.dnsConfig.mtime, the tryUpdate("/etc/resolv.conf") calls are noticing that /etc/resolv.conf's mtime does not match /tmp/foo/resolv.conf, and reloading the file.
The quick fix to restore the previous behavior would be changing forceUpdate to something like:
However, that feels hacky to me. I'm thinking writeAndUpdate should actually set lastChecked to far in the future to avoid it being reloaded, and then only teardown needs to zero out lastChecked.
For example,
/cc @mdempsky
The text was updated successfully, but these errors were encountered: