OPNsense Forum

Archive => 16.1 Legacy Series => Topic started by: mrkev on February 27, 2016, 05:32:49 pm

Title: [SOLVED] DNS Resolver failing to start after upgrade
Post by: mrkev on February 27, 2016, 05:32:49 pm
I upgrade from (I think) 16.1.3 to 16.1.4 and since then the DNS Resolver service fails to start. All I get in the logs is:

opnsense: /status_services.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1456589818] unbound[17195:0] debug: creating udp4 socket 0.0.0.0 53 [1456589818] unbound[17195:0] debug: creating tcp4 socket 0.0.0.0 53 [1456589818] unbound[17195:0] debug: creating udp6 socket :: 53 [1456589818] unbound[17195:0] debug: creating tcp6 socket :: 53 [1456589818] unbound[17195:0] debug: creating tcp4 socket 127.0.0.1 953 [1456589818] unbound[17195:0] debug: switching log to syslog'

I switched to DNS Forwarder which works ok but would like to go back to Resolver due to running my own domain.
Title: Re: DNS Resolver failing to start after upgrade
Post by: franco on February 28, 2016, 09:17:00 am
Unbound 1.5.7 has a bug we've pinned down and will fix for 16.1.5, details and workaround are here:

https://github.com/opnsense/core/issues/791

Please let me know if that solves your issue or if we have to investigate further. The error message you're seeing isn't very revealing, unfortunately.


Thanks,
Franco
Title: Re: DNS Resolver failing to start after upgrade
Post by: mrkev on February 28, 2016, 11:47:17 am
Hi,

that command (unbound-control-setup) worked. Thanks!
Title: Re: DNS Resolver failing to start after upgrade
Post by: Bouky on February 28, 2016, 02:21:33 pm
Hi,

+1

Same problem, same solution.

Thanks

Title: Re: [SOLVED] DNS Resolver failing to start after upgrade
Post by: franco on February 28, 2016, 04:06:07 pm
Luckily, FreeBSD has unbound installed in the base system... the "unbound-control-setup" from base kept working, but the GUI code actually runs the port version which is the faulty one. In any way, this will be fixed in 16.1.5 and I'll try to push the fix to FreeBSD ports as it effects all upstream builds of unbound 1.5.7.