[Xymon] Odd named errors, perhaps related to Xymon or Devmon?

[Jeremy Laidman]

On Tue, Sep 13, 2011 at 1:49 AM, Berkley, Simeon <
sberkley at mcclatchyinteractive.com> wrote:

> We've been getting an average of 40+/day of these messages from the
> caching nameserver process on one of our Xymon/Devmon servers:
>
>  named[N]: sockmgr 0xN: maximum number of FD events (64) received
>

This is a known condition (seems to be more common on Solaris) that you
shouldn't need to worry about.  You can get rid of the message by
recompiling BIND, if you're so inclined.

It's related to the way BIND asks the OS for any sockets with available
data.  BIND uses epoll_wait() to fill a buffer of sockets with data, but it
gives epoll_wait() a maximum number of sockets to return, so as to avoid
buffer overflow.  If the number of sockets with data is higher than the
complied maximum (64 by default), BIND logs the message, handles what's
returned from epoll_wait() and then loops around again.  No lost data is
indicated by this.


>  I
> have tried reproducing the problem by making a large amount of DNS
> lookups as simultaneously as possible, but with no luck.


Have you tried using "queryperf" from the BIND source?


> The xymonnet
> status only lists 42 failed DNS lookups out of 797 calls to
> dnsresolve. Any suggestions on how to find out what specific process
> is causing named to make periodic high demands for sockets?
>

Enable query logging and find out what queried domains are highest during
the interval.  This might give you a hint.

If you're only using BIND as a local caching nameserver, you could consider
instead using nscd, the name service caching daemon.  For most applications,
this is a more lightweight caching resolver.  It's not suitable for
everyone, but it might be just fine for your purpose, and you would no
longer see the error messages.

Cheers
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20110913/a38418f1/attachment.html>