Maintained by: NLnet Labs

[Unbound-users] Issues with Unbound 1.4.18

W.C.A. Wijngaards
Fri Aug 31 09:50:49 CEST 2012


-----BEGIN PGP SIGNED MESSAGE-----
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

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

iQIcBAEBAgAGBQJQQGzUAAoJEJ9vHC1+BF+NrbwQALDAtnaxd2K3KrhykhISGl4v
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
-----END PGP SIGNATURE-----