Maintained by: NLnet Labs

[Unbound-users] Issues with Unbound 1.4.18

Phil Davies
Fri Aug 31 13:45:24 CEST 2012

On 31/08/2012 08:50, W.C.A. Wijngaards wrote:
> 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,
>     Wouter
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> IR0bXDVB0o1F3UYJdiAl89OQG0SCQLEeltqA6UuKVRCeWSYUydc+k2qViDhcLj7n
> ieJWz/wz35UOUFbUsrhAUGKEa2CaZ9QJzTeF6d9qL+uLsNzSa69bf6kxSdgmUl62
> mVSZnKH3r7UCx9s9bMUJmSIG+Pxf7css9kW9UFe4vjRJxSekIGWR75MXBszkIlBM
> DO1MDbPhfJniSYfM6iI3FVQL97lLXvOdA5ahry6ZpCgXlMMMGL2UmD8TDMp/L4R4
> WzlDnAZcJqZt4G7wZRJrZtoDfgcR9nAf4+7tFN2oWAuxJMnsJm+GpSXKGD6oVTj2
> yG5pxUzlsgFUDaH5u2/nvWZie3r4KBLBqyLoFJ5ulJqBk6Bp57mIN6HXoYYMowXB
> 5e/sI0KCp0w/0WUg3JX8t4Tg/5QvHFWC+YNLo/e+JmVIAnb6HK0aisEmmFDhTqCA
> gAdn82xgKtt9jM3H3qqQvd2UxHOXuHALFk+I6TrMtfIOvajlZqcafTUOgZyUtctx
> yrfLGBc0eWwAYW18LnBZb+PxWUvIIvt2O9sVoj2Y5zmDCr38nKtMLNA/PctbWIbH
> tTdvlUqWEV2D7Uyx0NJjJkk+OVNkQRNgxDLee6fI+7CBWjM9yUkIR2KWqcWo7KWT
> S8gxanTgp2qELNO3hIWJ
> =ClQT
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at
Hi Wouter,

Thanks for the advice , I've recompiled unbound with debug enabled, So 
I'll wait until the next crash and see if I get any extra information. 
In terms of load these servers are doing about 1400 queries per second 
and when they are running handle this with about 10-15% CPU.  As for 
ulimit I haven't changed any defaults.