I've found that unbound crashes on OpenBSD after issuing the command: unbound-control reload:
# unbound-control reload
ok
ps agx |grep unbound
1367 p1 R+ 0:00.00 grep unbound (ksh)
# unbound-control start
[1229954623] unbound[26014:0] warning: increased limit(open files) from 128 to 312
[1229954623] unbound[26014:0] warning: did not exit gracefully last time (9217)
I'm using the latest patch release:
# unbound-control status
version: 20081218
verbosity: 1
threads: 1
modules: 2 [ validator iterator ]
uptime: 207 seconds
unbound (pid 6454) is running...
Wouter enjoys his christmas holidays at the moment, so let me answer
your e-mail.
It seems to work fine on Linux. Could you increase the verbosity level
to 4 (debug logs), or provide actual debugger output (for example, gdb
- --args unbound -d -vvvv; then 'run' and 'bt'), so we can see what is
actual going wrong?
Wouter enjoys his christmas holidays at the moment, so let me answer
your e-mail.
And a deserved one i guess
It seems to work fine on Linux. Could you increase the verbosity level
to 4 (debug logs), or provide actual debugger output (for example, gdb
--args unbound -d -vvvv; then 'run' and 'bt'), so we can see what is
actual going wrong?
I'm running Unbound on OpenBSD 4.4. And I think I know whats happening: it has something to do with the chrooted environment. This is the debug output:
/etc/unbound.conf:32: error: cannot open include file '/sidn/unbound/etc/unbound-sidn-overrides.conf': No such file or directory
read /etc/unbound.conf failed: 1 errors in configuration file
We have absolute paths in the unbound.conf, but the reload command work in the chrooted invironment. How to solve this?
So, if I understand correctly, unbound can open the include file, but
unbound-control not because the include file is outside the chroot
environment?
Can this be fixed with a symbolic link within the chroot environment
to
the include file?
Yep, this works.
In directory /sidn/unbound:
mkdir -p sidn/unbound/etc
cd sidn/unbound/etc
ln -s ../../../etc/unbound-sidn-overrides.conf
unbound-sidn-overrides.conf
# unbound-control reload
ok
But I find this strange behavior. I should guess, that in the
unbound/conf you should give only the relative paths to the chrooted
directory for includes. But this is only the case with reload, not when
starting Unbound.
But I find this strange behavior. I should guess, that in the
unbound/conf you should give only the relative paths to the chrooted
directory for includes. But this is only the case with reload, not when
starting Unbound.
That's why I've switched unbound in fedora to depend on SElinux, and got
rid of the entire chroot. (Still needs to propagate to EPEL and Fedora
releases)
That's why I've switched unbound in fedora to depend on SElinux, and got
rid of the entire chroot. (Still needs to propagate to EPEL and Fedora
releases)
Paul, is that just for you, or as an "official" maintainer of the package
for Fedora?
If the latter, then that would prevent me from running Unbound as I don't
have (or want) SELinux on my home machine.
> That's why I've switched unbound in fedora to depend on SElinux, and got
> rid of the entire chroot. (Still needs to propagate to EPEL and Fedora
> releases)
Paul, is that just for you, or as an "official" maintainer of the package
for Fedora?
It is currently only in rawhide, but the idea is to migrate it to the other
releases as well.
If the latter, then that would prevent me from running Unbound as I don't
have (or want) SELinux on my home machine.
From a distribution point of view, it makes no sense to keep small chroot
copies of the OS itself for various kinds of applications. Named I believe
laready lost its chroot as well.
There were various problems with the chroot. For one, there is the issue of
updated DNSSEC keys (via dnssec-keys and autotrust). Then there is the issue
of package updates and the --bind mounts not getting unmounted in time for
the package to do an update without causing problems in the scriptlets.
And last, with the coming of instant cheap VM's for a single purpose (eg
nameserver) the concept of chroot's is becoming rather useless. The only
value content of a VM running a nameserver is within the chroot itself.
I can see about adding an option for chroot building in the spec file, and
having it disabled per default, so you only need to rpmbuild the source rpm
with a --define 'use-chroot=yes' but I'd still prefer to just completely get
rid of it.
From a distribution point of view, it makes no sense to keep small
chroot
copies of the OS itself for various kinds of applications. Named I
believe
laready lost its chroot as well.
There were various problems with the chroot. For one, there is the issue
of
updated DNSSEC keys (via dnssec-keys and autotrust). Then there is the
issue
of package updates and the --bind mounts not getting unmounted in time
for
the package to do an update without causing problems in the scriptlets.
And last, with the coming of instant cheap VM's for a single purpose (eg
nameserver) the concept of chroot's is becoming rather useless. The only
value content of a VM running a nameserver is within the chroot itself.
