[ClusterLabs] Minor bug in SLES 15 corosync-2.4.5-6.3.2.x86_64 (unicast, ttl)
Jan Friesse
jfriesse at redhat.com
Fri Nov 20 08:21:56 EST 2020
Ulrich,
> Hi!
>
> A short notification:
>
> I had set up a new cluster using udpu, finding that ringnumber 0 has a ttl statement ("ttl: 1"), but ringnumber 1 had not. So I added one for ringnumber 1, and then I reloaded corosync via corosync-cfgtool -R.
probably ttl with value different from 1 right?
> Amazingly when (re)starting corosync, it failed with:
> Nov 19 15:29:51 h18 corosync[90724]: [MAIN ] parse error in config: Can only set ttl on multicast transport types
Yeah, old reload was quite flaky. 3.1.0 has way improved reload so it
would return error when config parsing or sanity checks failed.
>
> Independent of whether this may be true or not, it would be nice if it were handled consistently.
What you mean by "handled consistently"? Code is checking if transport
!= UDP (so multicast) and if ttl != 1 -> display error.
> Preferrably "ttl" would be just ignored with warning when not using multicast.
That doesn't sound like a good idea. User set something and may expect
that something is applied.
It may make sense to consider adding ttl support for other transports.
Regards,
honza
>
> Regards,
> Ulrich
>
>
>
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
>
More information about the Users
mailing list