problem with 9.9.6 and file descriptor limits
Alex
alex at 5252.ru
Tue Dec 2 05:24:46 UTC 2014
You are can run named with option "-S 8096" or more.
Also increase file limits in /etc/security/limits.conf
* soft nofile 8192
On 12/02/2014 07:23 AM, PORTER, BLAIR wrote:
>
> Hello, I recently compiled Bind 9.9.6, on RedHatas follows:
>
>
>
> BIND 9.9.6-S2 (Subscription Edition) <id:eb5b129c> built by make with
> '--enable-threads' '--enable-fixed-rrset'
> '--disable-openssl-version-check' '--with-openssl=no'
>
> compiled by GCC 4.1.2 20080704 (Red Hat 4.1.2-52)
>
>
>
> All seemed ok, except for 1 particular DNS server which had problems,
> getting messages in /var/log/messages at startup:
>
>
>
> Dec 1 10:23:24 clpi263 named[1297]: adjusted limit on open files from
> 16000 to 1048576
>
> Dec 1 10:23:24 clpi263 named[1297]: found 12 CPUs, using 12 worker
> threads
>
> Dec 1 10:23:24 clpi263 named[1297]: using 6 UDP listeners per interface
>
> Dec 1 10:23:24 clpi263 named[1297]: using up to 4096 sockets
>
> …
>
> …
>
> …
>
> Dec 1 10:23:25 clpi263 named[1297]:*socket: file descriptor exceeds
> limit (4096/4096)*
>
> Dec 1 10:23:25 clpi263 named[1297]: set up managed keys zone for view
> V049, file
> '/etc/namedb/Data/MKeys/98296d0c75d7c474f605af1e9e8f6bb6c7aa336f12e022a1819a891c73ae34d9.mkeys'
>
>
>
> Several of my views on that server had this message. I also found
> this in my normal DNS log file:
>
>
>
> 01-Dec-2014 11:45:35.473 general: critical: adb.c:2926:
> REQUIRE((options & 0x00000003) != 0) failed, back trace
>
> 01-Dec-2014 11:45:35.473 general: critical: #0 0x413e0b in
> assertion_failed()+0x4b
>
> 01-Dec-2014 11:45:35.473 general: critical: #1 0x5c319a in
> isc_assertion_failed()+0xa
>
> 01-Dec-2014 11:45:35.473 general: critical: #2 0x476ed4 in
> dns_adb_createfind2()+0x1044
>
> 01-Dec-2014 11:45:35.473 general: critical: #3 0x5336c7 in findname()+0xe7
>
> 01-Dec-2014 11:45:35.473 general: critical: #4 0x5392d5 in
> fctx_getaddresses()+0x3b5
>
> 01-Dec-2014 11:45:35.473 general: critical: #5 0x53ce5a in
> fctx_try()+0xcca
>
> 01-Dec-2014 11:45:35.473 general: critical: #6 0x543bb8 in
> fctx_start()+0x1a8
>
> 01-Dec-2014 11:45:35.473 general: critical: #7 0x5e2d1c in run()+0x2bc
>
> 01-Dec-2014 11:45:35.473 general: critical: #8 0x3a91407851 in
> _fini()+0x3a90e0e889
>
> 01-Dec-2014 11:45:35.473 general: critical: #9 0x3a90ce811d in
> _fini()+0x3a906ef155
>
>
>
> File descriptor limit info:
>
>
>
> ulimit –nS 1024
>
>
>
> ulimit –nH 4096
>
>
>
> my named process /proc//limits data is:
>
> Limit Soft Limit Hard Limit
> Units
>
> Max cpu time unlimited unlimited
> seconds
>
> Max file size unlimited unlimited
> bytes
>
> Max data size unlimited unlimited
> bytes
>
> Max stack size unlimited unlimited
> bytes
>
> Max core file size unlimited unlimited
> bytes
>
> Max resident set unlimited unlimited
> bytes
>
> Max processes 256388 256388
> processes
>
> Max open files 1048576 1048576
> files
>
> Max locked memory 65536 65536
> bytes
>
> Max address space unlimited unlimited
> bytes
>
> Max file locks unlimited unlimited
> locks
>
> Max pending signals 256388 256388
> signals
>
> Max msgqueue size 819200 819200
> bytes
>
> Max nice priority 0 0
>
> Max realtime priority 0 0
>
> Max realtime timeout unlimited unlimited
> us
>
>
>
> I don’t get this problem anywhere else, only on this 1 particular DNS
> server. It has many different views, and 15x virtual IPs, so I know
> it is a complex configuration. My previous version was bind 9.8.6-P1
> which ran just fine. I have read much information, but can’t seem to
> put my finger on the solution. I strongly suspect some type of O/S
> limit issue, not a problem with the Bind code.
>
>
>
> Help
>
>
>
> Blair Porter
>
> AT&T
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Kanogin Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20141202/542e0843/attachment-0001.html>
More information about the bind-users
mailing list