[ClusterLabs] Corosync 3.1.5 Fails to Autostart

[Ken Gaillot]

Hi,

With Corosync 3, node names must be specified in
/etc/corosync/corosync.conf like:

    node {
        ring0_addr: node1
        name: node1
        nodeid: 1
    }

(ring0_addr is a resolvable name used to identify the interface, and
name is the name that should be used in the cluster)

If you set up the cluster from scratch using pcs, it should do that for
you. I'm guessing you reused an older config, or manually set up
corosync.conf.

It shouldn't be necessary to change the After. If it still is an issue
after fixing the config, you might have some unusual dependency like a 
disk that gets mounted later, in which case it would be better to add
an After for the specific dependency.

On Mon, 2023-04-24 at 22:16 +0200, Tyler Phillippe via Users wrote:
> Hello all,
> 
> We are currently using RHEL9 and have set up a PCS cluster. When
> restarting the servers, we noticed Corosync 3.1.5 doesn't start
> properly with the below error message:
> 
> Parse error in config: No valid name found for local host
> Corosync Cluster Engine exiting with status 8 at main.c:1445.
> Corosync.service: Main process exited, code=exited, status=8/n/a
> 
> These are physical, blade machines that are using a 2x Fibre Channel
> NIC in a Mode 6 bond as their networking interface for the cluster;
> other than that, there is really nothing special about these
> machines. We have ensured the names of the machines exist in
> /etc/hosts and that they can resolve those names via the hosts file
> first. The strange thing is if we start Corosync manually after we
> can SSH into the machines, Corosync starts immediately and without
> issue. We did manage to get Corosync to autostart properly by
> modifying the service file and changing the After=network-
> online.target to After=multi-user.target. In doing this, at first,
> Pacemaker complains about mismatching dependencies in the service
> between Corosync and Pacemaker. Changing the Pacemaker service to
> After=multi-user.target fixes that self-caused issue. Any ideas on
> this one? Mostly checking to see if changing the After dependency
> will harm us in the future.
> 
> Thanks!
> 
> Respectfully,
>  Tyler Phillippe
-- 
Ken Gaillot <kgaillot at redhat.com>