>>> Bradley T Gill <[email protected]> schrieb am 28.07.2022 um 14:17 in Nachricht <[email protected]>: > Ulrich, > Thanks for the response. I have been considering that setting, but it is > unchanged from the previous version. I am concerned that it might break > applications that are expecting a persistent connection. It also seems to
> be growing so fast that there is a fundamental change somewhere. Hi! I had similar concerns; that's why I used the large value. But as an LDAP server can go down, clients should be able to handle if a connection goes down. Also (as I understand it), one request per day would keep the connection alive. OTOH: Does a connection that is not transferring a single packet within 24 hours have a justification to exist (consuming system resources on the server)? > I will add that I found that some overlay configs were missing including a > relay for Oracle searches. I am hoping that not knowing how to handle the > requests created the problem. Now that it is fixed, I am monitoring the > ports. Maybe try step 1: Who is opening those connections (on the client)? "netstat -tnp" on Linux if you still have netstat. Regards, Ulrich > > Thanks, > Bradley Gill, CISSP, CCSP > > -----Original Message----- > From: Ulrich Windl <[email protected]> > Sent: Thursday, July 28, 2022 5:35 AM > To: Bradley T Gill <[email protected]>; [email protected] > Subject: [EXTERNAL] Antw: [EXT] OpenLDAP 2.6 is holding connections open > > This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN > attachments. If suspicious please click the 'Report to Incidents' button in > Outlook or forward to [email protected] from a mobile device. > >>>> Bradley T Gill <[email protected]> schrieb am 27.07.2022 um 15:59 in >>>> Nachricht > <[email protected]>: >> All, >> I have been struggling with upgrading OpenLDAP from 2.4 to >> 2.5/2.6 > >> for some time. We have finally found that we needed to rebuild the schema >> from scratch and re‑add our customizations. The database is now running > much >> better with one lingering problem. Our Established connections just >> continues to grow until we run out of resources. Below is our >> cn=config (minus some unrelated info). This is on the same server as >> where the previous version was running, so changes are openldap and openssl > versions. > >> Any insights as to what might be causing the ESTABLISHED connections >> to continually grow would be very appreciated. >> >> # AUTO‑GENERATED FILE ‑ DO NOT EDIT!! Use ldapmodify. >> # CRC32 422b88f4 >> dn: cn=config >> objectClass: olcGlobal >> cn: config >> olcAttributeOptions: lang‑ >> olcConcurrency: 0 >> olcConnMaxPending: 100 >> olcConnMaxPendingAuth: 1000 >> olcGentleHUP: FALSE >> olcIdleTimeout: 0 > > What about "olcIdleTimeout: 86400" (or even more aggressive)? > In the past we had cases where applications opened new LDAP connections, > never reused or closed old ones. > >> olcIndexSubstrIfMaxLen: 4 >> olcIndexSubstrIfMinLen: 2 >> olcIndexSubstrAnyLen: 4 >> olcIndexSubstrAnyStep: 2 >> olcIndexHash64: FALSE >> olcIndexIntLen: 4 >> olcListenerThreads: 1 >> olcLocalSSF: 71 >> olcLogLevel: 256 >> olcLogFileOnly: FALSE >> olcMaxFilterDepth: 1000 >> olcReadOnly: FALSE >> olcSaslAuxpropsDontUseCopyIgnore: FALSE >> olcSaslSecProps: noplain,noanonymous >> olcSockbufMaxIncoming: 262143 >> olcSockbufMaxIncomingAuth: 16777215 >> olcThreads: 16 >> olcThreadQueues: 1 >> olcTLSCRLCheck: none >> olcTLSVerifyClient: never >> olcTLSProtocolMin: 0.0 >> olcToolThreads: 1 >> structuralObjectClass: olcGlobal >> creatorsName: cn=config >> createTimestamp: 20220726200129Z >> olcAuthzPolicy: any >> olcWriteTimeout: 30 >> olcSizeLimit: size.soft=unlimited size.hard=unlimited >> size.unchecked=unlimited >> size.pr=1000 size.prtotal=unlimited
