Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: resolv.conf recheck logic incorrect #10650

Closed
axaxs opened this issue Apr 30, 2015 · 14 comments

Comments

Projects
None yet
7 participants
@axaxs
Copy link

commented Apr 30, 2015

Resolv.conf errors are ignored during parsing as they should be. However, during recheck for file changes, any error occuring keeps the previous config. This should be changed so that it parses anyways. In cases where network is changed to say, setup a local resolver and remove resolv.conf, this change would never get picked up by a running program.

Further, changes detected in resolv.conf are never propagated up to main 'conf' for logic handling.

@axaxs

This comment has been minimized.

Copy link
Author

commented Apr 30, 2015

Will submit fix for this tonight

@mdempsky

This comment has been minimized.

Copy link
Member

commented Apr 30, 2015

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

@axaxs

This comment has been minimized.

Copy link
Author

commented Apr 30, 2015

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.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Apr 30, 2015

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

@gopherbot

This comment has been minimized.

Copy link

commented May 1, 2015

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

@axaxs

This comment has been minimized.

Copy link
Author

commented May 9, 2015

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?

@josharian

This comment has been minimized.

Copy link
Contributor

commented May 9, 2015

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).

@axaxs

This comment has been minimized.

Copy link
Author

commented May 9, 2015

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.

@davecheney

This comment has been minimized.

Copy link
Contributor

commented May 10, 2015

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.

@axaxs

This comment has been minimized.

Copy link
Author

commented May 12, 2015

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.

@josharian

This comment has been minimized.

Copy link
Contributor

commented May 12, 2015

@axaxs the discussion at #6670 should help some.

@axaxs

This comment has been minimized.

Copy link
Author

commented May 13, 2015

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.

@gopherbot

This comment has been minimized.

Copy link

commented May 13, 2015

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

@josharian

This comment has been minimized.

Copy link
Contributor

commented May 13, 2015

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.

@bradfitz bradfitz closed this in ef7e108 May 15, 2015

@mikioh mikioh added this to the Go1.5 milestone May 15, 2015

@golang golang locked and limited conversation to collaborators Jun 25, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.