corosync sends first time users on a hunt, simple fix

[flickerfly]

Corosync's init script properly fails to start by default to protect us. I get that, but the wild goose chase that a new user ends up on is a UX bug and in at least one case, I saw a user who simply changed distros because he couldn't figure it out claiming Ubuntu wasn't ready for business. (Yeah, I know that's nonsense but his complaint on spiceworks forums is among the top links on google for 'ubuntu corosync'. )

The puppet daemon does the same thing, but it has a bit of logic that when someone tries to start it and this file overrides them, it simply tells the user and tells them where to change the variable.

Here is the code they use in their init.

start_puppet_agent() {
    if is_true "$START" ; then
        start-stop-daemon --start --quiet --pidfile $PIDFILE \
          --startas $DAEMON -- $NAME $DAEMON_OPTS
    else
        echo ""
        echo "puppet not configured to start, please edit /etc/default/puppet to enable"
    fi
}

Here is the equivalent code in corosync's init.

do_start()
{
        # Return
        # 0 if daemon has been started
        # 1 if daemon was already running
        # 2 if daemon could not be started
        start-stop-daemon --start --quiet --exec $DAEMON --test > /dev/null \
                || return 1
        start-stop-daemon --start --quiet --exec $DAEMON -- $DAEMON_ARGS \
                || return 2
        # Add code here, if necessary, that waits for the process to be ready
        # to handle requests from services started subsequently which depend
        # on this one. As a last resort, sleep for some time.
        pidof corosync > $PIDFILE
}

I won't bother combining it as I find each item I try that the devs usually find my solution rather overly complicated. I'm sure you can handle it better than I.

[James Page (james-page)]

if [ "$START" != "yes" ]; then
    exit 0
fi

is the right place to log this messaging; lets update it there.

Thanks for the bug report!

[Rafael David Tinoco (rafaeldtinoco)]

Consider this during the Ubuntu HA effort.

[Rafael David Tinoco (rafaeldtinoco)]

Currently corosync is started by default with a single node ring formed with localhost:

(c)rafaeldtinoco@clusterdev:~/.../sources/ubuntu/corosync$ systemctl status corosync
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-03-19 20:16:49 UTC; 2min 10s ago
       Docs: man:corosync
             man:corosync.conf
             man:corosync_overview
   Main PID: 851 (corosync)
      Tasks: 9 (limit: 23186)
     Memory: 125.7M
     CGroup: /system.slice/corosync.service
             └─851 /usr/sbin/corosync -f

(c)rafaeldtinoco@clusterdev:~/.../sources/ubuntu/corosync$ sudo corosync-quorumtool
Quorum information
------------------
Date: Thu Mar 19 20:19:37 2020
Quorum provider: corosync_votequorum
Nodes: 1
Node ID: 1
Ring ID: 1.5
Quorate: Yes

Votequorum information
----------------------
Expected votes: 1
Highest expected: 1
Total votes: 1
Quorum: 1
Flags: Quorate

Membership information
----------------------
    Nodeid Votes Name
         1 1 node1 (local)

Because we try to make things "easier" (no failure on startups because the lack of configuration files, for example). Of course having a HA cluster is something beyond the scope of this bug and it might require an experienced system administrator to be able to make corosync to work in a meaningful way.

Nevertheless, for any future bug readers, may I recommend the following reading:

https://discourse.ubuntu.com/t/ubuntu-high-availability-shared-scsi-disk-environments/14874

in order to get a simple, yet supported, cluster configuration in a shared scsi environment.

Thanks for reporting this.