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.
Thanks again! Josh
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 have to your LDAP servers ?
There's not much traffic on them but those who need access need access.
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 connections do the servers have when this happens? I'm thinking you've run out of file descriptors (due to excessive connections, due to not using nscd and/or raising the file descriptor limit) which may be causing slapd to defer operations.
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 by slapd (which you configure via the loglevel directive in slapd.conf).
Regards, Buchan