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
sessions/socket.
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.
Regards,
--
Arjan Filius
iafilius@xs4all.nl