slapd Too many open files

Bug #632314 reported by Alex Harrington on 2010-09-07
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openldap (Debian)
Fix Released
openldap (Ubuntu)
openldap2.3 (Ubuntu)

Bug Description

I reported this back in 2007 on Dapper and we've been rolling custom debs since then.

Recently we've upgraded to lucid and are having the same issue again. After a short period of time with heavy load, we get:

Nov 19 10:23:03 core01 slapd[24753]: warning: cannot open /etc/hosts.deny: Too many open files

We've only got a few thousand users and <700 workstations using the directory so I can't see why nobody else would be seeing this issue.

Any chance of having the compile options changed on the official package so that this doesn't happen, or am I facing a further 5 years of rolling my own every time there's an update?

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

Changed in openldap2.3 (Ubuntu):
status: New → Invalid

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

Mathias Gug (mathiaz) wrote :

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

What's the system limit on opened files?

Changed in openldap (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
tags: added: patch

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.


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?

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?

Mathias Gug (mathiaz) wrote :

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.

Changed in openldap (Ubuntu):
status: Incomplete → Won't Fix

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.



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:

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....


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:


Thanks for the pointer!


This email carries a disclaimer, a copy of which may be read at

Changed in openldap (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.