After further log file analysis I found the blocking ldap query ... it is a
BIND request (which is successfull) and a missing CLOSE afterwards. After 5
minutes the LDAP Server closes the connection with closetype="T2" (server side
timeout). So far so good (client problem I will fix). I am not
Hello,
that is excellent news. The server was trying to read an operation for
5min then timeout (ioblock_timeout), I am a bit surprised it detected
incoming event but nothing to read. Anyway in such situation the
connection is locked and this explains why cn=monitor was hanging.
best
Thank you Thierry for your support.
So I will try to get the thread dump .. If the problem comes with a connection
timeout from a (not listening) client, shoudn´t I see an error log entry
somewhere? I searched for that for hours but no hints .. Maybe not the right
idea but the problem came
HI Erwin,
Just seeing your mail, I got a wild idea:
If I remember correctly a cn=monitor query collects some disk
statistics and to do
that it performs a stat on all mount points.
A problem with some nfs mounted file system could then explain the
delay.
It would be interesting
Hi Erwin,
I think the pstack is first step to diagnose what is going on. I
suspected a timeout because of the long etime (250s) that is close to a
5min timeout (ioblock, ssl timeout,...) but ATM there is no strong
evidence of this. timeout are not systematically reported in error logs
as it
Hi,
I would suspect the dump of the opened connections status to be the RC
of that delay. If the monitor thread can not acquire the connection
lock, it will delay the request. So I would suspect a connection timeout
(5min) to hang the monitoring thread, for example if a ldapclient is not
