I'm running OpenLDAP 2.3.30-5 on Debian 4. I checked the syslog and I found the following errors: slapd: warning: cannot open /etc/hosts.allow: Too many open files slapd: warning: cannot open /etc/hosts.deny: Too many open files
Please advice.
Thanks
Amir
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
--On February 12, 2008 3:25:46 PM +0200 Amir Saad eng__amir@hotmail.com wrote:
I'm running OpenLDAP 2.3.30-5 on Debian 4. I checked the syslog and I found the following errors: slapd: warning: cannot open /etc/hosts.allow: Too many open files slapd: warning: cannot open /etc/hosts.deny: Too many open files
Fix the number of file handles available.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Tuesday 12 February 2008 18:25:39 Quanah Gibson-Mount wrote:
--On February 12, 2008 3:25:46 PM +0200 Amir Saad eng__amir@hotmail.com
wrote:
I'm running OpenLDAP 2.3.30-5 on Debian 4. I checked the syslog and I found the following errors: slapd: warning: cannot open /etc/hosts.allow: Too many open files slapd: warning: cannot open /etc/hosts.deny: Too many open files
Fix the number of file handles available.
Or ensure that clients aren't abusing connections, and eating up the available file descriptors. For example, one thing to do is to ensure that clients run nscd (so each client creates only one connection to the server).
Regards, Buchan
--On February 12, 2008 6:54:07 PM +0200 Buchan Milne bgmilne@staff.telkomsa.net wrote:
On Tuesday 12 February 2008 18:25:39 Quanah Gibson-Mount wrote:
--On February 12, 2008 3:25:46 PM +0200 Amir Saad eng__amir@hotmail.com
wrote:
I'm running OpenLDAP 2.3.30-5 on Debian 4. I checked the syslog and I found the following errors: slapd: warning: cannot open /etc/hosts.allow: Too many open files slapd: warning: cannot open /etc/hosts.deny: Too many open files
Fix the number of file handles available.
Or ensure that clients aren't abusing connections, and eating up the available file descriptors. For example, one thing to do is to ensure that clients run nscd (so each client creates only one connection to the server).
Honestly I'm shocked to see nscd recommended given all the nightmares it causes people...
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount quanah@zimbra.com writes:
Buchan Milne bgmilne@staff.telkomsa.net wrote:
Or ensure that clients aren't abusing connections, and eating up the available file descriptors. For example, one thing to do is to ensure that clients run nscd (so each client creates only one connection to the server).
Honestly I'm shocked to see nscd recommended given all the nightmares it causes people...
Seems to work fine for us for caching LDAP replies on 100 machines or so (nothing fancy, just straight NIS schema). Just don't use it for DNS. :)
--On February 12, 2008 10:32:45 AM -0800 Russ Allbery rra@stanford.edu wrote:
Seems to work fine for us for caching LDAP replies on 100 machines or so (nothing fancy, just straight NIS schema). Just don't use it for DNS. :)
Hmm... I recall having to get Mike to kick nscd on the cluster several times because of the problems using it caused. But maybe he was doing name caching with it too. From what I remember though, the issue was it held "open" connections to downed servers.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Amir Saad wrote:
I'm running OpenLDAP 2.3.30-5 on Debian 4. I checked the syslog and I found the following errors: slapd: warning: cannot open /etc/hosts.allow: Too many open files slapd: warning: cannot open /etc/hosts.deny: Too many open files
Please advice.
Thanks
Amir
http://www.openldap.org/lists/openldap-software/200412/msg00106.html*
Express yourself instantly with MSN Messenger! MSN Messenger http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/
The reason for this error is you ran out of file descriptors for the slapd process. The default is 1024 for most systems. To up it for just slapd you can add: ulimit -n XXX Where XXX is the number of file descriptors you want to allow, I use 8192. Just add this line into the init script for slapd before you start slapd and this should resolve your issue.
David davidke@whidbey.net writes:
The reason for this error is you ran out of file descriptors for the slapd process. The default is 1024 for most systems. To up it for just slapd you can add:
ulimit -n XXX
Where XXX is the number of file descriptors you want to allow, I use 8192. Just add this line into the init script for slapd before you start slapd and this should resolve your issue.
Unless you're using i386 instead of amd64, at which point you'll still run into an upper limit on the select size.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378261 for more details. (Advice on whether the solution that I outline there is supported and reasonable is welcome.)
Russ Allbery wrote:
Daviddavidke@whidbey.net writes:
The reason for this error is you ran out of file descriptors for the slapd process. The default is 1024 for most systems. To up it for just slapd you can add:
ulimit -n XXX
Where XXX is the number of file descriptors you want to allow, I use 8192. Just add this line into the init script for slapd before you start slapd and this should resolve your issue.
Unless you're using i386 instead of amd64, at which point you'll still run into an upper limit on the select size.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378261 for more details. (Advice on whether the solution that I outline there is supported and reasonable is welcome.)
There's no 32 bit vs 64 bit distinction here. The distinction is whether you built on a newer kernel/glibc that supports epoll() vs an older platform that only supports select(). If you're using epoll() then the FD_SETSIZE definitions are completely irrelevant, and the ulimit is the only controlling factor.
Howard Chu hyc@symas.com writes:
There's no 32 bit vs 64 bit distinction here. The distinction is whether you built on a newer kernel/glibc that supports epoll() vs an older platform that only supports select(). If you're using epoll() then the FD_SETSIZE definitions are completely irrelevant, and the ulimit is the only controlling factor.
Aha! That explains it, and explains why I was confused. In that case, this bug is now fixed, and I'll close it. We disabled epoll for a while when we were still supporting Linux 2.4, but that's not been the case for some time.
Thank you very much for the explanation.
openldap-software@openldap.org
-
Amir Saad -
Buchan Milne -
David -
Howard Chu -
Quanah Gibson-Mount -
Russ Allbery