mirror of
https://github.com/abh/geodns.git
synced 2026-04-27 03:45:53 +03:00
[GH-ISSUE #69] Panic on deletion of broken zonefile #344
Labels
No labels
bug
bug
enhancement
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/geodns#344
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @abligh on GitHub (Aug 15, 2015).
Original GitHub issue: https://github.com/abh/geodns/issues/69
geodns panics if a broken zone file is created then deleted.
To replicate, create a broken zonefile:
Wait until the zone file fails to load:
Then delete the zone file
And wait a few minutes
The problem is this line:
As the zone file never existed, it has been incompletely loaded, and the metrics were not set up. Deleting it attempts to
Close()the zone file and this fails with anilpointer dereference asz.Metricsisnil.I would suggest zone files that are not present prior to loading and fail to load leave the zones map unchanged and do nothing. I will submit a changeset to fix this.
@abh commented on GitHub (Aug 15, 2015):
Woah, that's dumb. My zone files are almost always built by other tools so I haven't run into this. :-) Thank you. I'll have a look at your fix.
@abh commented on GitHub (Aug 21, 2015):
Hi Alex, I tried fixing it a little differently by not setting up the half-broken zone config when the file is invalid. I can't figure out why I was doing that in the first place, it just seems like it defeats the purpose. The intention was that if you screw up the zone data, the last loaded zone would remain active. I think it does that now (though I didn't explicitly test it or look carefully; it's late here now).
@abligh commented on GitHub (Aug 21, 2015):
I think the reason you may have done it the other way is to avoid it trying to load broken zone files every 5 seconds. Unless there is a zone stored, there is no
modtimestored, and on each poll it thinks it's a new file.@abligh commented on GitHub (Aug 21, 2015):
Oh, and I think the other issue may be that you want to keep the stats of zone files that are temporarily broken. Else they get cleared out and recreated across the file being broken and recreated.
@abh commented on GitHub (Aug 21, 2015):
Hmn, at a glance i don't think this clears out the stats as it leaves the old zones in place. The reloading every five seconds is a thing, yes. Hmn. Not sure if it matters, does it?
It's probably easy to fix for existing zones that gets mangled.
There's a race condition on line 34 anyway; it might be time to give this code a good overhaul. :-)
@abligh commented on GitHub (Aug 21, 2015):
I suspect the fix might be to take the mod time out of the Zone structure and only load zones into the slice when they are valid. I might take a look at that. I was thinking about putting fsnotify in too (though in the end decided it was overkill)
@abligh commented on GitHub (Aug 21, 2015):
I'm missing the race condition. Line 34 is:
The only thing that should be using
zonesis the thread that rereads the configs. The handlers themselves are passed theconfigstruct after this. What am I missing?@abh commented on GitHub (Aug 21, 2015):
Re your fix for the mod time: yes, please. That's what I'd been thinking, too. I had the same thought with fsnotify. Appealing, but too complicated.
The race is with the code in stathat.go (line ~25). I'm planning to just take the stathat stuff out and replace it either with something that talks to InfluxDB or (ideally) something more generic that just makes stats. My stats needs are a little weird because of the NTP Pool.
@abligh commented on GitHub (Aug 31, 2015):
Fix to mod time in pull request #77
@abligh commented on GitHub (Aug 31, 2015):
Re the StatHat thing, I suspect we need something that will iterate
Zonesunder a mutex or some other form of lock protection - probably not just StatHat that needs this. Perhaps aor similar.