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 to see if "df" command is responsive ...
(could be interesting to check the df output in sos report if you have it )
Regards,
Pierre
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 to see if "df" command is responsive ...
(could be interesting to check the df output in sos report if you have it )
Regards,
Pierre
On Mon, Jul 12, 2021 at 8:25 AM Erwin Weitlaner <erwin.weitlaner@tirol.gv.at> wrote:
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 after our last linux patch, so if others have similar problems maybe a code change issue?
SG Erwin
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
389 Directory Server Development Team
389 Directory Server Development Team
No comments:
Post a Comment