[ClusterLabs] Antw: Re: Antw: Is there a way to ignore a single monitoring timeout

[Klechomir]

On 1 Sep 2017, at 13:15, Klechomir <klecho at gmail.com 
<mailto:klecho at gmail.com>> wrote:
>>
>> What I observe is that single monitoring request of different 
>> resources with different resource agents is timing out.
>>
>> For example LVM resource (the LVM RA) does this sometimes.
>> Setting ridiculously high timeouts (5 minutes and more) didn't solve 
>> the problem, so I think I'm  out of options there.
>> Same for other I/O related resources/RAs.
>>
>
> hmm, so probably is something bad in clvm configuration? I use clvm in 
> three node cluster without issues. Which version of centos u use? I 
> experience clvm problems only on pre 7.3 version due to bug in libqb.

I have timeouts with and without clvm. Have it with resources managing 
(scst) iscsi targets as well.

>
>> Regards,
>> Klecho
>>
>> One of the typical cases is LVM (LVM RA)monitoring.
>>
>> On 1.09.2017 11:07, Jehan-Guillaume de Rorthais wrote:
>>> On Fri, 01 Sep 2017 09:07:16 +0200
>>> "Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de 
>>> <mailto:Ulrich.Windl at rz.uni-regensburg.de>> wrote:
>>>
>>>>>>> Klechomir <klecho at gmail.com <mailto:klecho at gmail.com>> schrieb 
>>>>>>> am 01.09.2017 um 08:48 in Nachricht
>>>> <9f043557-233d-6c1c-b46d-63f8c2ee59c7 at gmail.com 
>>>> <mailto:9f043557-233d-6c1c-b46d-63f8c2ee59c7 at gmail.com>>:
>>>>> Hi Ulrich,
>>>>> Have to disagree here.
>>>>>
>>>>> I have cases, when for an unknown reason a single monitoring request
>>>>> never returns result.
>>>>> So having bigger timeouts doesn't resolve this problem.
>>>> But if your monitor hangs instead of giving a result, you also 
>>>> cannot ignore
>>>> the result that isn't there! OTOH: Isn't the operation timeout for 
>>>> monitors
>>>> that hang? If the monitor is killed, it returns an implicit status (it
>>>> failed).
>>> I agree. It seems to me the problems comes from either the resource 
>>> agent or
>>> the resource itself. Presently, this issue bothers the cluster 
>>> stack, but soon
>>> or later, it will blows something else. Track where the issue comes 
>>> from, and
>>> fix it.
>>>
>>
>>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org <mailto:Users at clusterlabs.org>
>> http://lists.clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20170901/abc447db/attachment-0003.html>