[Date Prev][Date Next]
Re: slapd still allows bind but returns no data
Thanks everyone for the help!
I finally did see the infamous Too Many files open error in the logs.
I raised the ulimit -n to 2048 which was already set at 1024?
I am NOT using nscd on the ldap server but will enable that to see
what effects it has. Or were you asking if I use it on the clients?
I believe I am seeing a lot more connections than I originally
thought. Seems that all my servers ask LDAP for user info a lot more
than I had realized. nscd should help alleviate that tho I don't
like using it on most of my servers for reason unrelated to LDAP.
Anyway, I finally have some good answers and a few action items to
poke around with.
On Oct 15, 2007, at 11:57 AM, Buchan Milne wrote:
On Thursday 11 October 2007 20:45:21 Josh M. Hurd wrote:
I have been fighting with this issue for a couple months now and I
really need a solution.
I have 2 openldap servers recently upgraded to 2.3.38 with a brand
new rebuilt bdb from an LDIF dump.
The 2 servers sit behind a load balancer (read-only) and provide
basic authentication for about 300 linux servers.
Are these servers using nscd or not ? How many connections do they
your LDAP servers ?
There's not much traffic on them but those who need access need
The problem is they stop returning data, slapd is still running
otherwise seems ok.
Do you get any messages in the logs when this happens? How many
the servers have when this happens? I'm thinking you've run out of
descriptors (due to excessive connections, due to not using nscd
raising the file descriptor limit) which may be causing slapd to defer
You can still bind to them using rootdn with no issues.
I found an old thread describing a similar problem that suggested an
upgrade which I did.
I was using 2.2.13 now upgraded to 2.3.38
My level of knowledge of OpenLDAP is probably just above novice so I
don't have a good base for trouble shooting.
This is causing HUGE disruption and needs to be fixed immediately so
any and all help is much appreciated.
I turned on debug logging (-s 1) this morning so should have a bit of
data to share with you if need be.
Right, but this only allows you to direct *what* syslog will do
with the log
entries generated by slapd, not what level of logging is generated
(which you configure via the loglevel directive in slapd.conf).