[Unbound-users] Issues with Unbound 1.4.18

W.C.A. Wijngaards wouter at nlnetlabs.nl
Fri Aug 31 07:50:49 UTC 2012

Hash: SHA1

Hi Phil,

On 08/31/2012 09:28 AM, Phil Davies wrote:
> Hi,
> I have 6 DNS caching Resolvers serving many thousands queries.
> Until recently all 6 were running Bind. As i've heard such great
> things about Unbound I decided to switch 3 of them to Unbound. So
> i've installed the latest Unbound 1.4.18 with Libevent and at first
> things seemed good but i've noticed at least 4 times a day Unbound
> is crashing with:
> kernel: pid 82301 (unbound), uid 59: exited on signal 11
> I have a script that automatically restarts programs that should
> be running, so I didn't notice at first. I've tried tweaking loads
> of config options but nothing seems to make a difference. The
> servers aren't exactly that High spec:
> FreeBSD 8.3 Dual Core CPU 4G Ram
> However with Bind running the server is stable and if anything Bind
> uses a lot more CPU than Unbound for the same task. Can someone
> give me some idea's on what I can do to find out whats causing it
> to crash.

Get it to store coredumps.  Compile with debuginfo (-g option to gcc,
enabled by default I believe).  Store coredump with a ulimit statement
before you start the daemon to allow coredumps; I think it ends up in
the working directory.  Then use gdb executable coredump; bt for stack
backtrace.  (coredump without executable is not workable for me, I
would rather have the stack backtrace than the coredump itself).

A quick question, some people have ulimit set up to limit memory size
(heap size), and then configure unbound to use, e.g., XGb memory.
Does this seem the case?  (this seems more common on BSDs) (if its out
of memory unbound should still not segv, but print errors).

If the above fails, tcpdump to capture the packets at the time of crash.

If you compile with assertions enabled (debug-mode), then you might
get an assertion failure (and what line number it crashed on), and not
sigsegv.  Assertions are fairly cheap in performance terms.

The worst option for performance is to enable verbosity (level 4 or
so), it would likely slow down your system so that it could not handle
your incoming traffic any longer.  Produce Gbs of logfile.  More
useful if you can trigger the error yourself (thus keep logfile short).

Best regards,

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Unbound-users mailing list