Bug #4036
closedUnbound bails with "fatal error: Could not read config file: /unbound.conf"
0%
Description
I just upgraded a pretty heavily configured (many OpenVPN tunnels, QoS, 80-100 firewall rules, etc. on a 150/50Mbps connection) from 2.1.5->2.2 embedded from today; it's still reporting latest build at the time of this writing (built Sat Nov 22 01:52:19 CST 2014). I run the 4GB Embedded image on a 16GB mSATA card and only have a standard 1x LAN + 1x WAN setup. I've been running 2.2 without issue on a few other firewalls I manage but due to DNS complexity there were previously too many issues (all were reported/open). I noticed a rash of fixes for Unbound went in over the past few days and decided to give it a shot. It didn't fire up on first shot but a little digging on the surface reveals what I think should be a trivial issue. If I start Unbound from the GUI it immediately dies with:
Nov 22 10:50:13 scooby-sba unbound: [65007:0] fatal error: Could not read config file: /unbound.conf
Nov 22 10:54:33 scooby-sba unbound: [75650:0] debug: setup SSL certificates
Nov 22 10:54:33 scooby-sba unbound: [75766:0] debug: chdir to /var/unbound
Nov 22 10:54:33 scooby-sba unbound: [75766:0] debug: chroot to /var/unbound
Nov 22 10:54:33 scooby-sba unbound: [75766:0] debug: drop user privileges, run as unbound
I would see a few requests to my main resolvers via the WAN but no responses on the LAN. Thinking it was a config file issue I looked a bit deeper and it appears unbound is configured in most all places to properly get config from /var/unbound but the unbound app itself is compiled with a prefix of /usr/local/etc thus unbound looks in /usr/local/etc/unbound/ for configs if I run manually from the command line:
[2.2-BETA][root@scooby-sba.monroe.io]/etc/inc: unbound -h
usage: unbound [options]
start unbound daemon DNS resolver.
-h this help
-c file config file to read instead of /usr/local/etc/unbound/unbound.conf
file format is described in unbound.conf(5).
-d do not fork into the background.
-v verbose (more times to increase verbosity)
Version 1.4.22
linked libs: libevent 2.0.21-stable (it uses kqueue), OpenSSL 1.0.1i-freebsd 6 Aug 2014
linked modules: validator iterator
configured for amd64-portbld-freebsd10.1 on Tue Nov 18 11:41:10 CST 2014 with options: '--with-ssl=/usr' '--with-libexpat=/usr/local' '--disable-gost' '--with-libevent' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd10.1'
BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl
[2.2-BETA][root@scooby-sba.monroe.io]/etc/inc:
[2.2-BETA][root@scooby-sba.monroe.io]/etc/inc: which unbound
/usr/local/sbin/unbound
I never used the old Unbound port but could have some old config left over from a past upgrade attempt. What I've found so far is the following:
- If I add a symlink @ /usr/local/etc/unbound pointing to -> /var/unbound the client apps (e.g. unbound-control) would run without requiring the -c argument to point them to the config manually. If I launched unbound on the command line (either in foreground or background mode) it would handle requests for 30-60 seconds then bail.
- If I add a symlink @ /unbound pointing to -> /var/unbound and re-launch unbound in background mode from the command line it appears to stay running (it's been up for about 1.5 hours now with no issues).
- I could not find anywhere in the pfSense code where unbound was started with the incorrect chroot or -c option (that I recall, I only took a quick look) so this may be related to upgrade. Once I post this I plan to reboot and see if unbound starts on its own.
I'll attach my unbound.conf file; please let me know if I've got anything totally bad set in there (I'm new to unbound and set what seemed logical for my setup; I'll read up more on the individual options once the dust settles). If there's anything else I can test or further data I can provide just let me know. I did take a config backup before the upgrade so I can diff the before and after XML files if that would be helpful. Thanks guys and keep up the awesome work, 2.2 is shaping up to be awesome!!
-Chad
Files
Updated by Chris Buechler about 10 years ago
- Status changed from New to Feedback
pretty sure this is fixed after merging Warren's earlier pull request. I found a system where I could reliably replicate that, and no longer can after that change.
Updated by Chris Buechler about 10 years ago
- Status changed from Feedback to Resolved
others have confirmed fixed on forum thread