[Date Prev][Date Next] [Chronological] [Thread] [Top]

openldap 2.4.2[13] socket close bug ?

Hello openldap ml,

while researching more or less regular xen/centos/openldap crash situation, i ran into a
situation which i think is a (openldap) bug.

Tested with self compiled/packed openldap 2.4.21 and 2.4.23 on centos 5.2 64 bits

The most easy way to explain and test (for me) is:
1) Set threads to 2 in slapd.conf
2) Start a ldap search query which takes some time (say longer then a minute or so)
 ps: local or remote ldapsearch doesn't matter
 ps: i used ldapsearch and a "slowcat" to simulate
3) start a second ldap search querry as with 2)
4) Try to start a third ldapsearch query, which you may notice would
 connect (tcp backlog), but not yet handled by slapd.

Normally when the first ldapsearch session would stop, the third session
will be handled by slapd, which works just fine as expected, no need to test that now.

From now on you have some slightly different situations, which i will
number 5a ....)

5a) while those first 2 sessions are still running, and session 3 is waiting,
 lets kill session 1 or 2, and here it happens:
  -slapd won't log the killed session, and the third session isn't going
   to handled.
  -The third session is going to be handled as soon as the second session
   finishes in a normal way.

5b) while those first 2 sessions are still running, and session 3 is waiting,
 kill all ldap search querries (press ^C within your ldapsearch for
 example) , and here it happens:
  -slapd won't log died sessions
  -new ldapsearch sessions are accepted by the backlog buffer, but are
   never going to be accepted by the slapd process.
  -when stopping slapd it complains about closing already died

So it looks like killed sessions, are not quite handled correctly within
slapd, and i noticed as soon there is one session which finishes in a normal way, it will also clear and free the killed sessions. The other way arond, when killing all sessions, you've a denial of service, and no session will ever be cleared.

Please confirm or deny, feedback welcome.


Arjan Filius