[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