Comment 31 for bug 1740892

My findings from today:

1) This situation has always existed on Trusty, afaict. Removing the regression related tag.

2) There are 24 possible combinations to consider (some are by definition green already, but I'm including them for completeness; and some are not achievable) for each release: `service {start,stop,restart} {corosync,pacemaker}` where each of corosync and pacemaker can begin in one of {started,stopped}; 3 * 2 * 2 * 2 = 24.

3) For now, I'm ignoring the case of pacemaker configured to use heartbeat, as that is not the default in the current Ubuntu release.

4) On Trusty, 6 of those combinations are not possible by default (corosync stopped but pacemaker running).

5) On Trusty, the only failing situation I can provoke is `service restart corosync` when corosync and pacemaker are running already. In all other 17 cases, the expected result is obtained with existing packages.

6) I have submitted an MP to the Ubuntu Server Git repository for general review and submitted a build to a PPA at: https://launchpad.net/~nacc/+archive/ubuntu/lp1740892/, which adds a manual SysV start of pacemaker in corosync's SysV restart logic, if pacemaker was running before corosync was restarted. I think this is the least likely path to affect any existing configurations. In particularly, this does not affect the corosync start path, which may or may not have previously started pacemaker (that is a local configuration decision, afaict).

7) In my investigation (this relates to xnox's and other's comments), there is no SysV link between pacemaker and corosync. Instead, pacemaker itself quits due to not finding corosync if it's not already started. This is why the SysV do_stop routine for corosync ends up resulting in pacemaker stopping.