https://bugs.openldap.org/show_bug.cgi?id=9190

--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- I've tried reproducing via a script, and while I get the same searches, I do not get the err=4. The difference seems to be the fact that when the error is seen, the system is under load with multiple connections and searches occurring, while my test is while the system is idle. It makes me wonder if this is an initialization bug similar to bug#9052.

Mar 21 22:44:32 localhost slapd[30041]: conn=2623 fd=23 ACCEPT from IP=xx.yyy.zz.aa:38002 (IP=0.0.0.0:389) Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=0 BIND dn="cn=admin,dc=xxx,dc=yyy" method=128 Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=0 BIND dn="cn=admin,dc=xxx,dc=yyy" mech=SIMPLE ssf=0 Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=0 RESULT tag=97 err=0 qtime=0.000017 etime=0.671021 text= Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=1 SRCH attr=namingContexts Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000034 etime=0.675941 nentries=1 text= Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=2 SRCH base="dc=xxx,dc=yyy" scope=2 deref=0 filter="(uid=*)"

(search continues until I kill it, as we clearly never hit the size limit)

https://bugs.openldap.org/show_bug.cgi?id=9190

--- Comment #3 from Quanah Gibson-Mount quanah@openldap.org --- As an aside, idletimeout does not appear to be functioning correctly. On the dev system, have set a 300 second idletimeout:

idletimeout 300

which is 5 minutes.

a) Connect at 23:24:37, go idle:

Mar 21 23:24:37 ldapdev0 slapd[71056]: conn=1003 fd=23 ACCEPT from IP=xx.yy.zz.aa:57006 (IP=0.0.0.0:389)

b) have a connection connect after 5 minutes, 10 seconds. This should force the cleanup routine to drop the connection, but this is not what I see:

Mar 21 23:29:49 ldapdev0 slapd[71056]: conn=1004 fd=24 ACCEPT from IP=xx.yy.zz.aa:58508 (IP=0.0.0.0:389)

This is clearly 5 minutes, 12 seconds later -- connection was not dropped, but it should have been.

c) My test connection, which is supposed to reuse the file descriptor in (a) does not do this, when it connects at:

Mar 21 23:30:37 ldapdev0 slapd[71056]: conn=1005 fd=24 ACCEPT from IP=xx.yy.zz.aa:58742 (IP=0.0.0.0:389)

In fact, the connection does not get dropped until:

Mar 21 23:31:52 ldapdev0 slapd[71056]: conn=1003 fd=23 closed (idletimeout)

Nearly 7.5 minutes later.

https://bugs.openldap.org/show_bug.cgi?id=9190

--- Comment #4 from Howard Chu hyc@symas.com --- (In reply to Quanah Gibson-Mount from comment #3)

As an aside, idletimeout does not appear to be functioning correctly. On the dev system, have set a 300 second idletimeout:

idletimeout 300

which is 5 minutes.

In fact, the connection does not get dropped until:

Mar 21 23:31:52 ldapdev0 slapd[71056]: conn=1003 fd=23 closed (idletimeout)

Nearly 7.5 minutes later.

Working as designed. It only checks timeouts every timeout/4 seconds; doing so more frequently was considered too expensive.