Re: File descriptor leak, slapd hangs and runs out of file descriptor

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On January 2, 2008 5:14:25 PM -0500 Sam Tran <stlist@gmail.com> wrote:

> Dear All,
>
> We are running OL 2.3.39 on Centos 5 i386 or x86_64. We have one
> provider and three consumers (LDAP-sync repl).
>
> Several applications perform LDAP write and read operations on the
> provider.
>
> For the second time in 2 months, we had what it looked like a file
> descriptor leak on the provider: file descriptors were not closed at
> all or fast enough. At the same time, slapd was unresponsive. Here is
> what the logs shows:
>
> I restarted slapd, which fixed the problem.
>
> The first time that problem occurred, slapd ran out of file descriptor.
> I don't know what triggered the problem. Prior to the problem there
> was no increase in load, all LDAP operations were performed
> successfully.
>
> I would appreciate it if anyone could give me some pointers on how to
> troubleshoot the problem.

I don't see any issue here -- Every connection takes a file descriptor. 
Most of the things opening connections aren't being closed in the log 
snippet you show, so they hold onto the resource.  The connections that it 
does show closed, the fd is freed, and then the next incoming connection 
uses it.  I.e., no evidence of a leak.  One of the first things I always do 
with my LDAP servers is to bump up the number of file descriptors available 
to slapd (usually to 16k on 64-bit boxes).  Many things uses persistent 
connections, which uses up file descriptors.  You could also implement a 
harsh idletimeout (like idletimeout of 5 seconds) to kick off idle 
persistent connections.  How well clients handle that is variable though.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration