ldap connection failed / reason:emfile / ssl_esock issue

[Aaron C. de Bruyn]

I upgraded to the ejabberd package in universe (2.0.1-2~hardy1)

After running for a few days, I get this in my ejabberd.log:

=ERROR REPORT==== 2009-03-14 08:53:17 ===
W(<0.364.0>:eldap:566) : LDAP server closed the connection: lv-server.smiles.local:636
In State: active

=INFO REPORT==== 2009-03-14 08:53:17 ===
I(<0.364.0>:eldap:898) : LDAP connection on lv-server.smiles.local:636

=ERROR REPORT==== 2009-03-14 08:57:17 ===
W(<0.278.0>:eldap:566) : LDAP server closed the connection: lv-server.smiles.local:636
In State: active

The next two lines repeat until I kill the ssl_esock process, then things start working normally again:

=INFO REPORT==== 2009-03-14 08:57:17 ===
I(<0.278.0>:eldap:898) : LDAP connection on lv-server.smiles.local:636

=ERROR REPORT==== 2009-03-14 08:57:17 ===
E(<0.278.0>:eldap:915) : LDAP connection failed on lv-server.smiles.local:636
Reason: emfile

This appears to be due ssl_esock using up more and more connections when the Windows AD/LDAP server closes the connection.
More and more sockets are used up, eventually they are unable to allocate more.

[Aaron C. de Bruyn (darkpixel2k)]

As a workaround, I added this to my crontab:
@daily killall ssl_esock

I can reproduce this fairly constantly--it just takes a few days to show up.
Downgrading to the earlier version of ejabberd did not fix the problem.

[Walter Huf (hufman)]

Debian upstream fixed it in ejabberd_2.0.1-3, while my computer is running ejabberd_2.0.1-2
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490059#84
Can we have this backported?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.