Unbound problems after update to latest beta
-
Just a newb question here, but after the change is committed an upgrade will implement it, correct? Just making sure I won't still have to implement the patch at that point if I'm not a fresh install. I'm currently not experiencing any issues but thought I'd ask. Thanks!
Correct. If the patch gets committed, it will be included in whatever the next snapshot is after it gets committed.
How fast it gets committed depends entirely on people who experienced the previous issues testing it and providing feedback, though.
-
Jim's first reply is correct, I was the one who did the original bug report on this.
Previously unbound was quick on boot because it didnt actually check if it had started ok, it simply ran a kill command immediately followed by a start command (this was actually done on the wan ip change process). The problem was if the kill process had not finished then the start command would fail but the pfsense boot scripts were unaware of this.
My original proposed fix was to issue a shutdown command to unbound to stop it, which can take time to complete especially when there is a large dnsbl list. Hence the delay on boot and restarts.
Better to have the delay than a service that hasnt started.
bbcan177 the developer of pfblockerng confirmed the bug also.
-
Better to have the delay than a service that hasnt started.
That was my thought as well, except in practice this led to people not having any running unbound instance, or one left running but in a weird/broken state (e.g. stuck at 100% CPU).
Unbound's official docs actually say to stop it with kill, which is still what my last patch does, but it also waits ~30 to let it stop nicely before attempting to start it again.
-
yep I can see from the posts here the fix hasnt worked for everyone, hopefully these guys will test the new patch to confirm its good for them.
-
I hope so, too. I have not received any feedback about the patch I posted here (or on the Redmine ticket). I could not reproduce the problems here, so I'd rather not commit it without verifying it works properly on firewalls that exhibited the previous problems.
-
I hope so, too. I have not received any feedback about the patch I posted here (or on the Redmine ticket). I could not reproduce the problems here, so I'd rather not commit it without verifying it works properly on firewalls that exhibited the previous problems.
Hmm, in reply #13 I gave feedback, I believe. Works fine, I have not upgraded my installation since.
-
I hope so, too. I have not received any feedback about the patch I posted here (or on the Redmine ticket). I could not reproduce the problems here, so I'd rather not commit it without verifying it works properly on firewalls that exhibited the previous problems.
Hmm, in reply #13 I gave feedback, I believe. Works fine, I have not upgraded my installation since.
I must have missed the "edit:". I do not get notified on post edits like I do for replies, it's not a very effective way to convey an update like that.
-
Ah, sorry, I'll post a second answer for things like this in the future. But it would be great if the others in this thread could give it a shot, too.
-
I went ahead and committed the updated patch, we'll see how that goes.
-
I can't say whether the issue I'm experiencing is related to this one, but it's been consistent for a while that I have to restart unbound after updating or rebooting pfsense or else nslookup and dig will fail. This is only using the snapshot, not 2.3.4. I am using the "do not wait for RA" feature. Otherwise my system is quite simple and uses defaults almost exclusively.
Here are the details: https://forum.pfsense.org/index.php?topic=132181.0
-
I'm not sure what's going on here, but while swapping modems this afternoon (upgraded to a DOCSIS 3.1 modem), I had my pfSense WAN interface not connected for a bit. After reconnecting it, and just now looking in the DNS Resolver logs, I have extended the log view up to 5000 lines and over 95% of the lines are…
Jul 18 17:30:46 unbound 82208:1 error: can't bind socket: Can't assign requested address for x.x.x.xor replace the IPv4 address with an IPv6 address. The timestamp is the exact same to the minute, with a variance of 3 seconds over more than 4900 lines. That's some MAJOR log spamming going on while the connection is down.
Maybe it's always done that and I just haven't noticed (I don't tend to look at dns resolver logs often)… but that's pretty severe to be writing over 4900 lines to a log file in just three seconds. Possibly related? If not, please feel free to split this to a new topic.
