Discussion:
[Unbound-users] error when threading enabled on local_unbound on FreeBSD 10.x
u***@fongaboo.com
2015-07-20 03:15:16 UTC
Permalink
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
[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


-------------------------------------------------------------------------
shot through the heart ooh baby do you know what that's worth
and you're to blame ooh heaven is a place on earth
darling you give love they say in heaven love comes first
a bad name we'll make heaven a place on earth
ORBITAL "Halcyon Live"
l***@kwsoft.de
2015-07-20 07:06:36 UTC
Permalink
Post by u***@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
[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
# 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
Jaap Akkerhuis
2015-07-20 08:30:20 UTC
Permalink
Post by u***@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
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
u***@fongaboo.com
2015-07-20 21:47:35 UTC
Permalink
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?
|
| >
| >
| >
| > > 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
|
| 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.
+1, there is a good reason the local_unbound config file is hidden some
place *not* in /etc, and automatically generated. It s because you DO NOT
touch it. It is to be used as a local resolver only. If you want to use
unbound for something else, you install it from ports.
--
Mathieu Arnold
Jaap Akkerhuis
2015-07-21 05:48:46 UTC
Permalink
Post by u***@fongaboo.com
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.
Post by u***@fongaboo.com
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
u***@fongaboo.com
2015-07-21 15:58:43 UTC
Permalink
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
Post by Jaap Akkerhuis
Post by u***@fongaboo.com
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.
Post by u***@fongaboo.com
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
Norberto Altalef
2015-07-21 16:13:15 UTC
Permalink
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




<http://www.redklee.com.ar>

www.redklee.com.ar
tel [+54] 11 5273 6342
cel [+54 9] 11 5055 9853
linkedin <http://ar.linkedin.com/in/norbertoaltalef/>
Post by u***@fongaboo.com
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
Post by u***@fongaboo.com
Post by u***@fongaboo.com
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
Post by u***@fongaboo.com
while stock unbound has them in /usr/local/etc/unbound?
Yes.
Post by u***@fongaboo.com
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
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
Jaap Akkerhuis
2015-07-21 16:43:05 UTC
Permalink
Post by u***@fongaboo.com
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
Post by Jaap Akkerhuis
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
u***@fongaboo.com
2015-07-21 16:52:21 UTC
Permalink
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
Post by Jaap Akkerhuis
Post by u***@fongaboo.com
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.
Post by u***@fongaboo.com
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
Jeremy Shaffner
2015-07-21 20:59:13 UTC
Permalink
To be clear, this is how $PATH works on any shell on any Unix like system.
Post by u***@fongaboo.com
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
Post by u***@fongaboo.com
Post by u***@fongaboo.com
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
Post by u***@fongaboo.com
while stock unbound has them in /usr/local/etc/unbound?
Yes.
Post by u***@fongaboo.com
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
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
--
Jeremy Shaffner
Director of Information Technology
Convo™ | convorelay.com
<http://media.convorelay.com/brand/email_sig/website.html?utm_campaign=sent-mail&utm_medium=email&utm_source=website>
***@convorelay.com





Voice: *925-480-7770* VP: 240-751-4749
u***@fongaboo.com
2015-07-21 22:30:05 UTC
Permalink
Surely... Just that I gather this conundrum only arises for those using
FreeBSD with the built-in local_unbound implementation.
Post by Jeremy Shaffner
To be clear, this is how $PATH works on any shell on any Unix like system.
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
Post by u***@fongaboo.com
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.
Post by u***@fongaboo.com
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
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
--
Jeremy Shaffner
Director of Information Technology
Convo? | convorelay.com
Voice: 925-480-7770 VP: 240-751-4749
Loading...