corosync sends first time users on a hunt, simple fix
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
corosync (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned |
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_
if is_true "$START" ; then
--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
|| return 1
|| 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.
if [ "$START" != "yes" ]; then
exit 0
fi
is the right place to log this messaging; lets update it there.
Thanks for the bug report!