> On 3 Jan 2020, at 07:14, Marc Sauton wrote:
>
> the build string
> 389-Directory/1.3.9.1 B2019.164.1418
> corresponds to a RHEL-7.7 with RHDS-10.4
> to verify:
> cat /etc/redhat-release; rpm -q redhat-ds 389-ds-base
>
> the access and errors log snippets are showing a "normal" timeout after
the build string
389-Directory/1.3.9.1 B2019.164.1418
corresponds to a RHEL-7.7 with RHDS-10.4
to verify:
cat /etc/redhat-release; rpm -q redhat-ds 389-ds-base
the access and errors log snippets are showing a "normal" timeout after
10mn, when there is no activity, and they do not really provide
Hi Steve,
We see it happening with replication connections from other 389 DS servers
in the cluster (but because it is multi-master, other replications masters'
succeed, so its OK).
However, we also see it with other clients - they will initiate a
connection, but the connection will hang and the
Is it possible that that application is pro-actively creating LDAP connections
that it does not use? This scenario might happen if the application is using
connection pooling.
-Original Message-
From: Trevor Fong
Sent: Thursday, January 2, 2020 10:16 AM
To:
Happy New Year, everyone!
Further to this, I added connection management loglevel to the errorlog level
and managed to capture the output during one of the events when the connection
seems to stall. Would anyone be able to help me make sense of it?
Thanks a lot,
Trevor Fong
Access log:
