https://bugs.openldap.org/show_bug.cgi?id=9197
Bug ID: 9197 Summary: slapd-ldap/slapo-chain hits error 80 after idletimeout Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs@openldap.org Reporter: quanah@openldap.org Target Milestone: ---
From a customer:
In order to communicate via the LB managed writable ldap, we have to ensure that an idle connection is periodically refreshed. If we do not, the LB will silently drop the connection after 5 minutes.
Therefore to combat that I set an olcIdleTimeout on the writable server so that the chain cached connections will be removed before the LB timeout hits.
However the slapo-ldap client goes into CLOSE_WAIT state, which causes subsequent ldapmodify updates being brokered by the read only instance to fail with err=80. There appear to be a few bugs filed on this in the past against slapd-ldap, but it's not clear if we may be hitting the same issue, or if this is a new one.
I've also connected the read only instances directly to the writable ldap instances and the CLOSE_WAIT issue persists, so I don't believe the CLOSE_WAIT issue is caused by the LB
These were the other threads I found as I started looking for this problem, these are using the ldap-proxy though I think: https://www.openldap.org/lists/openldap-technical/201301/msg00323.html http://www.openldap.org/lists/openldap-software/201004/msg00060.html https://www.openldap.org/lists/openldap-bugs/200412/msg00029.html
The LB we have seems to be set to forget connections that last over 5 min per the setting, so the 240:10:30 seemed like it should have worked and I just thought it wasn't working because in the man page the text "Only some systems support the customization of these values" is present. however after setting keepalive to 60:10:30 did I maintain a stable connection, so there may be other network settings at play I'm not aware of.