Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jun 2007 18:50:14 +0200
From:      "Ulrich Spoerlein" <uspoerlein@gmail.com>
To:        stable@freebsd.org
Subject:   Re Unix domain socket leak in 6-STABLE
Message-ID:  <7ad7ddd90706130950v48686221t5f27945607789c94@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
On 6/13/07, Ivan Voras <ivoras@fer.hr> wrote:
> Can you perhaps isolate the bug / give more information on it? I'm
> asking because I'm currently using an application with unix domain
> sockets in production wich handles lots of connects/disconnects per
> second and it doesn't seem to show leakage.

Ok, I'm not exactly sure what I should do. First of all, there are two
LDAP consumers: postfix and cyrus-saslauthd. A fairly common setup, I
suppose.

If I bombard this setup with hundreds of mails, cyrus is at one point
unable to process the mails further, stating that:
Jun 13 18:27:22 misctest1 lmtpunix[47460]: IOERROR: opening
/data/cyrus/spool/user/ulrspoe/cyrus.cache: Too many open files

The error is misleading, though, as it is not cyrus that is out of
file descriptors, but rather OpenLDAP. Restarting slapd will make
cyrus work again.

I logged the lsof output during the mail bomb and the slapd-lines are
continually rising:

misctest1# while :; do echo -n `date` "  "; lsof 2>/dev/null | awk '$1
~ /imapd/{imapd+=1} $1 ~ /slapd/{slapd+=1} $3 ~ /postfix/{pf+=1}
END{print imapd, pf, slapd}'; sleep 60;done
Wed Jun 13 18:21:55 CEST 2007   1378 71 272
Wed Jun 13 18:22:57 CEST 2007   1378 71 272
Wed Jun 13 18:23:58 CEST 2007   1378 216 316
Wed Jun 13 18:24:59 CEST 2007   1378 321 644
Wed Jun 13 18:26:01 CEST 2007   1378 333 1132
Wed Jun 13 18:27:02 CEST 2007   1378 329 1804
Wed Jun 13 18:28:04 CEST 2007   1378 417 2280

The third column never goes down significantly. I have the setup now
sitting at 2k open files for the slapd process and will wait until
tomorrow, if the count ever decreases again.

Changing from
ldapi://%2fvar%2frun%2fopenldap%2fldapi/ to ldap://127.0.0.1/ "fixes"
the problem. It might be a genuine problem in OpenLDAP, though. We are
using openldap-server-2.3.34_1

Cheers,
Uli



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7ad7ddd90706130950v48686221t5f27945607789c94>