Description of problem: After the most recent update of bind (version bind-9.3.6-4.P1.el5_5.3), now when you restart the named daemon you get the following message on Syslog (facility: daemon, severity: warning): max open files (1024) is smaller than max sockets (4096) This happens with the latest kernel: 2.6.18-194.26.1.el5 Version-Release number of selected component (if applicable): bind-9.3.6-4.P1.el5_5.3 on RHEL 5.5 How reproducible: Steps to Reproduce: 1.service named restart 2.Watch /var/log/messages or anywhere you get daemon-facilty/warning messages.
I initially reported this on the CentOS list along with the suggested workaround: http://lists.centos.org/pipermail/centos/2010-December/102882.html
I can confirm this issue on my RHEL 5.5 box. -- Eero
You can workaround this bug if you set "files 4096;" option in the options {} section in your named.conf.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
This is a regression from RHBA-2009-0246 which has open files limit set to "unlimited" by default
(In reply to comment #6) > This is a regression from RHBA-2009-0246 which has open files limit set to > "unlimited" by default To be precise, this is not regression from RHBA-2009-0246, let me explain this issue in detail. There were two bugs in RHEL-5 version of BIND related to "unlimited" open limit by default: 1. by default bind set limit to 1024 2. there is an issue in the kernel which prevents to set limits to "unlimited" (http://kerneltrap.org/mailarchive/linux-kernel/2008/9/9/3238694). In the RHBA-2009-0246 we fixed only the "1.", the second issue is still present. Rebase from 9.3.4 to 9.3.6 version exposes this bug because new BIND issues warning when files limit is too low. So I would rather not call this bug as Regression because the second issue was never fixed. Removing Regression keyword.
(In reply to comment #3) > You can workaround this bug if you set "files 4096;" option in the options {} > section in your named.conf. Should all users apply this workaround, or is it strictly only necessary on high-volume servers? (Can the limit only be hit with ~1024 concurrent connections?)
(In reply to comment #15) > (In reply to comment #3) > > You can workaround this bug if you set "files 4096;" option in the options {} > > section in your named.conf. > > Should all users apply this workaround, or is it strictly only necessary on > high-volume servers? > (Can the limit only be hit with ~1024 concurrent connections?) Users should apply this workaround when recursive server denies clients and system log (/var/log/messages) contains errors from named daemon which say certain operations fail due file limit. If you don't see any error in the log, you don't have to apply the workaround.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0254.html