slapd Too many open files

Sorry. Marked against the wrong package. It's 2.4.21

I've built new packages with the debian.rules file patched as attached and will test over the next couple of days.

Thank you for taking the time to report this bug and helping to make Ubuntu better.

What's the system limit on opened files?

root@core01:~# su openldap
root@core01:~# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

On Dapper however we found that increasing the open files only prolonged the time before we had this problem.

I'm already running the package I compiled up yesterday. I'll let that run for a few days or until the ldap server stops responding and then look at changing the limits here too.

Alex

slapd fell over again this morning. I'm trying editing /etc/security/limits.conf

openldap hard nofile 8096
root hard nofile 8096

in conjunction with modified packages. I'll report back.

Ended up with adding

openldap soft nofile 8096
openldap hard nofile 8096
root soft nofile 8096
root hard nofile 8096

Rebooted. ulimit -a as root/openldap shows the change but still the system goes unresponsive and I get the too many open files message.

Does anyone have anything else to suggest?

http://readlist.com/lists/openldap.org/openldap-software/2/12904.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378261

Both worth reading. I've tried adding a ulimit -n 8192 as suggested in /etc/defaults/slapd so I'll see if that fixes things.

After a couple of days with:

ulimit -n 8192

in /etc/defaults/slapd we've not had a recurrence so I'll cautiously say it looks like that solves it. It's really strange however that adding the same limit via /etc/security/limits doesn't have the same effect?

Marking this bug won't fix as there is a workaround now.

You may wanna file a new bug against the relevant package to raise the potential issue with /etc/security/limits.

Alex, have you tried going back to using the stock Lucid version of the slapd binary (but with the /etc/defaults/slapd ulimit changes)?

(The very last comment on Debian bug 378261 seems to indicate that the -DOPENLDAP_FD_SETSIZE=8192 patch shouldn't actually make any difference in the Lucid version.)

I will do next time I do updates on that server. I don't want to take the service down at the moment given the trouble we've had up until now.

Cheers

Alex

I noticed that this very topic (the default file descriptor limit) is currently being discussed on the ubuntu-dev mailing list.

In particular, there was a little discussion of the fact that /etc/security/limits.conf does not apply to services:
  https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031493.html

The thread also covers various situation where otther applications are hitting the limit; if you (Alex) are lucky perhaps something there will give you an idea why you are doing so but other sites don't seem to be....

Nathan

On Mon, Sep 20, 2010 at 14:39:27 -0000, Nathan Stratton Treadway wrote:
> (The very last comment on Debian bug 378261 seems to
> indicate that the -DOPENLDAP_FD_SETSIZE=8192 patch
> shouldn't actually make any difference in the Lucid
> version.)

The bug is currently closed, but just in case new comments
are ever posted to it, here's a direct link to the specific
one to which I was referring:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378261#52

Nathan

Thanks for the pointer!

Alex

This email carries a disclaimer, a copy of which may be read at http://learning.longhill.org.uk/disclaimer