On Friday, December 19th, 2025 at 10:49 PM, [email protected] <[email protected]> wrote:
> I sent only to misc@ because I don't believe this to be a bug. > > On Fri, Dec 19, 2025 at 08:25:18AM +0000, Otto Cooper wrote: > > > chrooted unbound is the default in openbsd. > > chrooted unbound has its configuration file in /var/unbound/etc. The > > command "rcctl \ > > reload unbound" fails because it looks for the configuration in /etc. To > > solve this \ > > problem, the rc.d config for reloading the daemon needs to be pointed at \ > > /var/unbound/etc. > > As mentioned before unbound runs chrooted to /var/unbound so after chroot is > in effect > logs and such will say /etc/unbound.conf but in really is > /var/unbound/etc/unbound.conf. > Also of note unbound changes userid to _unbound so permissions must be for > that user. According to the debug log, root starts the daemon reading /var/unbound/etc/unbound.conf, then enters /etc in the chroot and drops *user* privileges to run as _unbound. After that, in the log any reference to /etc/unbound.conf truly means /etc in the chroot. The log could be nicer: knowing that the daemon is chrooted, as it does, because it appears in the debug log, it could mention it in the non-debug log when it refers to a file in the chroot. When running from rcctl, the default non-debug log does not mention the chroot. Anyway, this would be a courtesy to the busy reader. You do not spend time on unbound, as it is one of the few "set and forget" things, so you re-learn and improve it only when it breaks. > > > cat /var/unbound/etc/unbound.conf > > > server: > > > include: "/var/unbound/etc/local.unbound" > > > use-syslog: no > > > logfile: /var/unbound/log/current > > > ls -l /var/unbound/etc/local.unbound > > > > > -rw-r----- 1 root wheel 2957 Dec 12 10:46 local.unbound > > Your unbound service will NOT be able to read this file! > Unbound is running as user _unbound:_unbound so none of the permissions match. > OpenBSD's default permissions in 7.8 (and Dec 19th snapshot) is root:wheel > -rw-r--r-- > for files in /var/unbound/etc/. You are on the same page. > Note: the _unbound user has read-only access (good security). No, if you set the file owner to _unbound, it has write access. > -rw-r----- 1 _unbound wheel 2957 Dec 12 10:46 local.unbound ....^ > Either "chmod 644 local.unbound" or "chgrp _unbound local.unbound". > Be sure unbound.conf also has correct permissions or chmod/chgrp. > Syslog is the default for logging but as you did you can specify your own log > file. > Be sure the _unbound user has write access here. > Using db directory as template guide: > Set /var/unbound/log to root:_unbound drwxrwxr-x and > set logfile current to _unbound:_unbound -rw-r--r--. This is how I have at this time. >ls -halFR /var/unbound /var/unbound: total 40 drwxr-xr-x 5 root wheel 512B Oct 12 20:32 ./ drwxr-xr-x 32 root wheel 1.0K Dec 18 13:23 ../ drwxrwxr-x 2 root _unbound 512B Dec 19 23:41 db/ drwxr-xr-x 2 root _unbound 512B Dec 20 09:02 etc/ drwxr-xr-x 2 root _unbound 512B May 11 2023 log/ /var/unbound/db: total 24 drwxrwxr-x 2 root _unbound 512B Dec 19 23:41 ./ drwxr-xr-x 5 root wheel 512B Oct 12 20:32 ../ -rw-r--r-- 1 _unbound _unbound 1.2K Dec 19 23:41 root.key /var/unbound/etc: total 3800 drwxr-xr-x 2 root wheel 512B Dec 20 09:02 ./ drwxr-xr-x 5 root wheel 512B Oct 12 20:32 ../ -rw-r----- 1 root _unbound 1.7M Mar 22 2023 blacklist.unbound -rw-r--r-- 1 root _unbound 386B Aug 10 2020 dlv.isc.org.key -rw-r----- 1 root _unbound 622B Aug 11 2020 example.unbound -rw-r----- 1 root _unbound 930B Aug 11 2020 invalid.unbound -rw-r----- 1 root _unbound 3.4K Aug 11 2020 local.unbound -rw-r--r-- 1 root _unbound 3.2K Aug 11 2020 named.root -rw-r----- 1 root _unbound 1.9K Aug 11 2020 test.unbound -rw-r--r-- 1 root _unbound 2.4K Dec 20 09:02 unbound.conf -rw-r----- 1 root _unbound 2.4K Aug 10 2020 unbound_control.key -rw-r----- 1 root _unbound 1.3K Aug 10 2020 unbound_control.pem -rw-r----- 1 root _unbound 2.4K Aug 10 2020 unbound_server.key -rw-r----- 1 root _unbound 1.3K Aug 10 2020 unbound_server.pem -rw-r--r-- 1 root _unbound 608B May 11 2023 unbound_stub_zones.conf /var/unbound/log: total 4176 drwxr-xr-x 2 root _unbound 512B May 11 2023 ./ drwxr-xr-x 5 root wheel 512B Oct 12 20:32 ../ -rw-rw---- 1 root _unbound 2.0M Dec 20 09:35 current I hope it is enough. I should not be doing it, however. I expect sane defaults instead. > > In summary, to solve this problem, I had to make the following two changes > > to \ > > openbsd's base installation of unbound: > > In /etc/login.conf > > > > > unbound:\ > > > > > > > openfiles-max=8192:\ > > > > tc=daemon: > > I don't understand why unbound wants so many openfiles, my running system > never shows > more than 400 files opened systemwide (sysctl kern.nfiles) and I'm running > two unbound services. > But it does seem to complain (but continue) with the default openfiles=512. This is what I have at this time: >doas sysctl kern.nfiles kern.nfiles=1645 But it is saturday. On a busy wednesday it is much higher. > For what it's worth, on my system I set openfiles=1024 and in unbound.conf I > use: > outgoing-range: 950 > num-queries-per-thread: 512 > For good(?) measure I recently added "num-threads: 4" (I settled on four > after monitoring, > but having just 1 thread has always worked too) Unbound's directions are a mixed match here. Since we have libevent, their recommendation is outgoing-range: 4096 num-queries-per-thread: 2048 > Since I have a second unbound running named unbound2 in /etc/rc.d I also had > to create: > $ cat /etc/login.conf.d/unbound2 > unbound2:\ > :tc=unbound: > to pick-up the same settings for both instances. A single daemon with libevent seems beafy enough nowadays. > > and > > > > doas chown _unbound /var/unbound/etc/* > > I wouldn't do that, leave the files owned/writable only by root, readable by > _unbound (or other). Done. > > I see something new in the log above: > > > > Dec 19 17:48:49 unbound[55896:0] warning: setsockopt(..., SO_SNDBUF, ...) > > was not \ > > granted: No buffer space available Dec 19 17:48:49 unbound[55896:0] > > warning: \ > > so-sndbuf 4194304 was not granted. Got 9216. To fix: start with root \ > > permissions(linux) or sysctl bigger net.core.wmem_max(linux) or \ > > kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value). > > See https://marc.info/?l=openbsd-bugs&m=176026002606676&w=2 Great catch, in the bugs list. > cfg->so_rcvbuf = 0; > - cfg->so_sndbuf = 4*1024*1024; > + cfg->so_sndbuf = 1*1024*1024; According to the unbound recommendations, both rcv and snd should be 4m. https://unbound.docs.nlnetlabs.nl/en/latest/topics/core/performance.html > Upstream changed default for so-sndbuf to 4M, OpenBSD is different (see > thread). > Stuart set it to 1M in OpenBSD so if you are getting this error you most > likely > are setting so-sndbuf in your config (or did the 1.24.2 import loose this > setting?) > > In my system I had added "so-sndbuf: 2m" (even before upgrading to 7.8). 2m is the maximum I could set manually. I would love to know the difference between these: so-sndbuf: 0 so-sndbuf: 2m I guess 0 truly means 9216, which is this value: #net.inet.udp.sendspace=9216 # default This is the alternative I am using, but I prefer to put it back to the default and use so-sndbuf instead. >doas sysctl net.inet.udp.sendspace net.inet.udp.sendspace=2089999 > I use a handful of values from nlnetlabs's tunning guide: > https://unbound.docs.nlnetlabs.nl/en/latest/topics/core/performance.html#configuration > "man unbound.conf" has very good descriptions of all the settings, a must > read!
