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.
** Changed in: corosync (Ubuntu)
Status: Triaged => Fix Released
** Changed in: corosync (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1239734
Title:
corosync sends first time users on a hunt, simple fix
Status in corosync package in Ubuntu:
Fix Released
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1239734/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
