Error when threading enabled on local_unbound on FreeBSD 10.x

Unbound
1

I was setting up local_unbound (the built-in instance of unbound in FreeBSD 10.x). However, I had a conf file that I had a much more customized from a previous install of the stock unbound I had on earlier box.

When I tried to transplant the more elaborate conf and have local_unbound run it, I got the following errors:

[1437336832] unbound[69115:0] warning: too many file descriptors requested. The builtin mini-event cannot handle more than 1024. Config for less fds or compile with libevent
[1437336832] unbound[69115:0] warning: continuing with less udp ports: 211
[1437336832] unbound[69115:0] debug: switching log to syslog

I bit-by-bit added on section at a time to unbound.conf until I found the offender was this entry:

   # number of threads to create. 1 disables threading. This should equal the number
   # of CPU cores in the machine. Our example machine has 4 CPU cores.
   num-threads: 4

Why would threading cause these errors? What is the default setting when the entry is commented out?

TIA

2

Zitat von unbound@fongaboo.com:

I was setting up local_unbound (the built-in instance of unbound in FreeBSD 10.x). However, I had a conf file that I had a much more customized from a previous install of the stock unbound I had on earlier box.

When I tried to transplant the more elaborate conf and have local_unbound run it, I got the following errors:

[1437336832] unbound[69115:0] warning: too many file descriptors requested. The builtin mini-event cannot handle more than 1024. Config for less fds or compile with libevent
[1437336832] unbound[69115:0] warning: continuing with less udp ports: 211
[1437336832] unbound[69115:0] debug: switching log to syslog

I bit-by-bit added on section at a time to unbound.conf until I found the offender was this entry:

  # number of threads to create. 1 disables threading. This should equal the number
  # of CPU cores in the machine. Our example machine has 4 CPU cores.
  num-threads: 4

Why would threading cause these errors? What is the default setting when the entry is commented out?

To my knowledge the number of threads is 1 by default. For the relation of file descriptors with threads and other settings have a look here: http://www.unbound.net/documentation/howto_optimise.html

Regards

Andreas

3

lst_hoe02@kwsoft.de writes:

>
>
> Zitat von unbound@fongaboo.com:
>
> > I was setting up local_unbound (the built-in instance of unbound in
> > FreeBSD 10.x). However, I had a conf file that I had a much more
> > customized from a previous install of the stock unbound I had on
> > earlier box.
> >
> > When I tried to transplant the more elaborate conf and have
> > local_unbound run it, I got the following errors:

This is a FreeBSD issue. The local_unbound thingy is configured
just for running a local resolver/cache. If you want to run a full
blown unbound resolver which should serve also other machines on
you network, you are better off with disbaling the local_unboun and
install & run the one from the ports.

  jaao

4

Thanks,

I am now attempting to install from ports. However, am I gathering correctly that FreeBSD's local_unbound's config files live in /etc/unbound while stock unbound has them in /usr/local/etc/unbound?

When I run unbound-control-setup, it seems to put the files it generates in /etc/unbound anyway. What do I have to do to make sure everything defaults to the stock setup instead of the local_unbound setup?

5

unbound@fongaboo.com writes:

>
>
> Thanks,
>
> I am now attempting to install from ports. However, am I gathering
> correctly that FreeBSD's local_unbound's config files live in /etc/unbound
> while stock unbound has them in /usr/local/etc/unbound?
>

Yes.

> When I run unbound-control-setup, it seems to put the files it generates
> in /etc/unbound anyway. What do I have to do to make sure everything
> defaults to the stock setup instead of the local_unbound setup?

Note your $PATH

Make sure that you use the /usr/local/sbin/unbound-control-setup
(and others from the ports). The /usr/sbin/$unboundtools have wired
in the /etc as defaut path.

Alternatively always usr the -f config with the build-in
versions.

  jaap

6

Thanks. This clarifies a lot.

This may be a stupid FreeBSD question, rather than an unbound-specific question, but is there any way to give the executables in /usr/local/sbin priority when running them from the path?

FONG

7

I’m not a FreeBSD user, but I think you must put /usr/local/sbin before in your PATH variable.

This would be a security risk if your /usr/local is accesible by others users in the system

Best regards

Norberto

8

unbound@fongaboo.com writes:

>
>
> Thanks. This clarifies a lot.
>
> This may be a stupid FreeBSD question, rather than an unbound-specific
> question, but is there any way to give the executables in /usr/local/sbin
> priority when running them from the path?
>
> FONG

That is what I meant with:

> > Note your $PATH

For me, echo $PATH gives something like:

/home/jaap/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/bin:

So, looking for an executable it first looks in my private bin
(/home/jaap/bin:) directory, then in the local directories
(/usr/local/sbin:/usr/local/bin:).

You can change the search order by rearranging this order. See man
sh (or man csh, or man bash, dependent on what your actual shell
is) for details.

  jaap

9

Thanks... Sent me further down the right path (both literally and figuratively).

What I did was... I created a subdir /usr/local/etc/unbound/sbin

Then I added this to the top of the $PATH priority by editing .cshrc.

Then I made a bunch of symlinks from /usr/local/sbin/unbound-* to /usr/local/etc/unbound/sbin

This forced it such that when I run unbound-<whatever> from CLI anywhere, it defaults to the stock version and not the FreeBSD local_unbound version.

For good measure, in case I ever want to run local_unbound for anything, I made a bunch more symlinks from /usr/sbin/unbound-* to /usr/local/etc/unbound/sbin/local_unbound-*

Hopefully this might be helpful to some FreeBSD users in the same situation...

FONG

10

To be clear, this is how $PATH works on any shell on any Unix like system.

11

Surely... Just that I gather this conundrum only arises for those using FreeBSD with the built-in local_unbound implementation.