When I normally start a mariadbd with

systemctl start mariadb

it forms its own cluster (but instead it should join the the other 2 nodes of the cluster, aka. it is bootstrapping). This should NOT happen. Relevant config:

1. grep -r wsrep *
   mariadb.conf.d/60-galera.cnf:# See the examples of server wsrep.cnf files in /usr/share/mysql
   mariadb.conf.d/60-galera.cnf:wsrep_on = ON
   mariadb.conf.d/60-galera.cnf:wsrep_provider = /usr/lib/galera/libgalera_smm.so
   mariadb.conf.d/60-galera.cnf:wsrep_cluster_name = "MariaDB Galera Cluster"
   mariadb.conf.d/60-galera.cnf:wsrep_cluster_address = gcomm://192.168.56.103,192.168.56.133,192.168.56.134
   mariadb.conf.d/60-galera.cnf:wsrep_node_address = 192.168.56.133
   mariadb.conf.d/60-galera.cnf:wsrep_sst_method = rsync

I had this already 24 hours ago with a completely other cluster after upgrading to 10.5.9 (Ubuntu 20.04). This one was a fresh install. I never have seen this symptom before. So I assume it was introduced with 10.5.9. And it is somehow not too difficult to reproduce. But I do not know yet how exactly.

After rebooting the machine the problem disappeared automatically and node joined to the cluster. So I assume it has to do with the variables the wsrep_new_cluster is setting or not removing any more.
I think it has to do with the hang of wsrep_new_cluster which has happened in an earlier try and after I killed wsrep_new_cluster the variables are somehow still there (globally).

Pretty evil surprise because it also happens on an already running system and this bug is introduced with the upgrade.

If you have a hint how to reproduce I can try. I will keep this testing system for a while...