[ClusterLabs] Antw: Re: Fwd: "Funny" message from corosync (SLES12 SP4)

[yren]

Hello Ulrich,

Thanks for your report, this bug fixed to the upstream.

https://github.com/corosync/corosync/commit/2a4cd3c4af0256cc79e1ed1c7f070fd469e4cfaf

Here, I'd like to recommend to use `token`, `token_retransmit`, 
`token_retransmits_before_loss_const` and `hold` by default as 
corosync.conf(5) said. But now, if you specified the `token_retransmit` 
as 30, the error wouldn't occur again. But once you specified up to 33, 
the situation would be a little complex, it means the `token` you have 
to specified and must more than 1000 (default is 1000) or set 
appropriate `token_retransmits_before_loss_const`. So, again, we don't 
recommend to set these values without instruction.

If you have any questions, please feel free to contact with me.

Bests,

Yuan

On 5/9/19 10:16 AM, yren wrote:
> Hello Ulrich,
>
> Nice catch, this is absolutely a bug still exist in corosync 3. I have 
> pull a request and waiting for the further discussion from upstream.
>
> https://github.com/corosync/corosync/pull/464
>
> Regards,
>
> Yuan
>
> On 5/6/19 3:10 PM, Ulrich Windl wrote:
>> Hi!
>>
>> Thanks for the explanation. Unfortunately I did delete the bad config 
>> files in the mean time. But the first problem may have been triggered 
>> by trying to set "token_retransmits_before_loss_const: 30".
>>
>> Regards,
>> Ulrich
>>
>>>>> yren <yren at suse.com> schrieb am 05.05.2019 um 12:40 in Nachricht
>> <e31414f1-981f-d971-8c69-24c028a8caa6 at suse.com>:
>>> Hello Ulrich,
>>>
>>> 1. "corosync[13979]:   [MAIN  ] parse error in config: The token hold
>>> timeout parameter (16 ms) may not be less than (30 ms)."
>>>
>>> ----There is no difference between corosync 1 (SLES11 SP4) and corosync
>>> 2 (SLES12 SP4). The error occurred because you specified the "hold" in
>>> totem less than 30 ms (I guess, because there is no config file you
>>> provided) . This is not allowed. Please reference corosync.conf(5). The
>>> 30ms is come from "(int)(1000/HZ)*3", the HZ used is 100 because it
>>> stands for the low utilization of CPU.
>>>
>>> 2. "corosync[13979]:   [MAIN  ] interface section bindnetaddr is used
>>> together with nodelist. Nodelist one is going to be used"
>>>
>>> ----- This is a wired problem, the nodelist must be specified if you 
>>> use
>>> UDPU as the totem.transport with bindnetaddr. If you want to figure out
>>> the reason caused that, please publish the config file.
>>>
>>>
>>> Regards,
>>>
>>> Yuan
>>>
>>> On 4/25/19 9:05 PM, Roger Zhou wrote:
>>>> Hi Yuan,
>>>>
>>>> I'm wondering you might have some clue, coincidentally with your
>>>> recent finding?
>>>>
>>>> Cheers,
>>>> Roger
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: *Ulrich Windl* <Ulrich.Windl at rz.uni-regensburg.de
>>>> <mailto:Ulrich.Windl at rz.uni-regensburg.de>>
>>>> Date: Tue, 23 Apr 2019 at 10:33
>>>> Subject: [ClusterLabs] "Funny" message from corosync (SLES12 SP4)
>>>> To: <users at clusterlabs.org <mailto:users at clusterlabs.org>>
>>>>
>>>>
>>>> Hi!
>>>>
>>>> Fighting with the cahnges between corosync 1 (SLES11 SP4) and corosync
>>>> 2 (SLES12 SP4), I got some "funny" error message:
>>>> corosync[13979]:   [MAIN  ] parse error in config: The token hold
>>>> timeout parameter (16 ms) may not be less than (30 ms).
>>>>
>>>> The funny part is that "hold" is not set at all in the config file!
>>>>
>>>> I guess it's auto-computed from other parameters.
>>>>
>>>> The other funny thing is when following corosync.conf.example.unicast
>>>> (using interface and nodelist), I see this message:
>>>> corosync[13979]:   [MAIN  ] interface section bindnetaddr is used
>>>> together with nodelist. Nodelist one is going to be used.
>>>> corosync[13979]:   [MAIN  ] Please migrate config file to nodelist.
>>>>
>>>> I guess the sample is not up-to-date...
>>>>
>>>> Regards,
>>>> Ulrich
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Manage your subscription:
>>>> https://lists.clusterlabs.org/mailman/listinfo/users
>>>>
>>>> ClusterLabs home: https://www.clusterlabs.org/
>>
>>
>>
>>