Will submit fix for this tonight

Tangentially, we should probably be rechecking /etc/nsswitch.conf too.

I checked on this when bfitz brought up that we probably shouldn't, and glibc does not recheck nsswitch.conf. See Notes section - http://linux.die.net/man/5/nsswitch.conf. I'm not opposed to it, just bringing it up.

Let's not do more than glibc does. DNS and wifi settings change often. Nsswitch doesn't.

CL https://golang.org/cl/9580 mentions this issue.

I've abandoned the CL for this due to pushback in review.

I'm now wondering if the recheck logic can be removed altogether and exposed as an exported function instead (similar to res init) so that the application can do this instead. Would save a goroutine and constant file stat'ing. I can't remember now why it was added, I think Docker wanted it for something.

Thoughts? Or is this the wrong forum?

I pushed for the auto-recheck; the beacon wasn't picking up changes as it joined and left wifi networks. I'm not sure an exported function is necessary, although instead of an always-on goroutine, one could instead have each request check the most recent update time and do the update if it is too old (or kick off a short-lived goroutine to do the update).

Thanks, that makes some sense. That seems reasonable, too. Either seems saner, since both would simplify the code and prevent the extra goroutine and 5 second outage incurred in cases where it switches. Curious to know thoughts of others, too.

I like that idea, make it a private function to begin with. Exporting or automating it can happen later.

On 10 May 2015, at 05:50, Alex Skinner notifications@github.com wrote:

I've abandoned the CL for this due to pushback in review.

I'm now wondering if the recheck logic can be removed altogether and exposed as a function instead (similar to res init) so that the application can do this instead. Would save a goroutine and constant file stat'ing. I can't remember now why it was added, I think Docker wanted it for something.

Thoughts? Or is this the wrong forum.

—
Reply to this email directly or view it on GitHub.

I wrote a patch for this tonight but other things dawned on me. Cgo doesn't do any rechecking, so you could theoretically run into a situation where go picks up a new resolv.conf, but a strangely encoded hostname kicks it to cgo which will presumably then fail. I have no idea what windows does, but this seems to be inconsistent. Does this matter to anyone?
Assuming none of that matters, is it preferred that
a - every lookup kicks off a stat and checks modtime
b - every lookup kicks off a stat if x seconds have passed since the last one (and what is x?)
c - a stat/recheck is only kicked off if there is an error during lookup

Sorry to make a fuss about this, I dread this default DNS changing in the current state.

@axaxs the discussion at #6670 should help some.

Thanks Josh. I submitted https://go-review.googlesource.com/#/c/9991/, please take a look since you also have a vested interest in this logic. Overall, I'm still not overly pleased with either method and think it should ultimately be relegated to occur on errors or else not at all and defer to the client, so I won't be overly upset if you like the old style better. A discussion for another time I suppose. This bug should be fixed either way, so if you have reasons to prefer the extra goroutine, I'll just abandon and open another that addresses only this bug.

CL https://golang.org/cl/9991 mentions this issue.

I'll take a look at CL 9991 soon, perhaps after Brad's first round of comments has been addressed. I never particularly liked the extra goroutine, and I'm happy to hear that it is going away.