Solved: unbound can't start after snapshot update
Just upgraded to latest 2.0 snap:
built on Wed Feb 2 22:47:47 EST 2011
And unbound did not start. I saw this in the system log:
php: : The command '/usr/local/sbin/unbound-control start' returned exit code '127', the output was '/usr/local/sbin/unbound-control: not found'
So I reinstalled the package and then it started fine.
Any errors when it reinstalled the package when it booted back up for the first time?
I've seen that too, but wait really loooooong time! The reinstallation of the packages in the background needs really much more time than before. When it was done via the webinterface, it was done in about max 5 minutes. Now it needs about 1 hour! I fell into the same hole, but when looking at the monitor attached at my pfSense-box, i could see that. So a login via ssh doesn't show you that process, and the log shows but when using the shaper, it gets filled with "bump shed buckets"-messages, so you maybe don't see that reinstallation as continuous entries! By the way, there should be the "Update in progress-picture" at the webinterface.
While the update is in progress, you see the respective services stopped, but all start with the time. Unbound too. (In my case)
same here …
tomorow, ill try again with newest snapshot pf20
i hope theres no big issue with newest snapshot
well … after upgrade to new snapshoot
package are : squid, squidguard,lightsquid, vnstat and unbound ...
some weird with unbound, after reboot there is no error show up on terminal
only : syncing packages : unbound, no get finish up boot ...
but i can get acces to gui ...
and weird get again, when save on gui unbound, its stale, for all tab gui ...
meanwhile no problem with accessing inet ....
so disable for while ...
i just report it ...
keep good work
i'll see if I can reproduce this and let you guys know.
Any updates on this? Stopped using Unbound because I update quite often and was locked out the last time.
HI guys, apologies for delayed response. Moving house has been a little nightmarish.
Awhile back I added "Cache Restoration Support" which dumps the cache on shutdown and loads it when it is booting. This is to obviously speed up name resolution.
Have you guys got this enabled? As I do see a race condition in this and when packages are syncing. So i will need to sort this one out but I just want to make sure this is where the problem is.
Congrats on the new move!
Yes, I did have Cache Restoration Support Enabled.
In the interim disable 'Cache Restoration' and it should then work correctly. I should have a fix out this weekend.
Wagonza, is this still actively being worked on or is the solution more problematic than initially estimated?
I committed some changes today - try them it out and let me know how it goes.
built on Thu Mar 3 19:27:51 EST 2011
Working fine here. Thanks. Updated the subject of OP to reflect.