<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> You'd think that would help, but<br>><br>> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=880035">https://bugzilla.redhat.com/show_bug.cgi?id=880035</a> suggests otherwise.<br>> I have one remaining fedora machine where KVM clusters still work, I<br>
> don't think I'll ever update it now.<br>></blockquote><div><br></div><div>Well, that was fascinating read.</div><div><br></div><div>Using the udpu transport seems to have stabilized corosync.  If I understand that bug report correctly I should also see better multicast behavior if I enable the <span style="white-space:pre-wrap">multicast_querier, but I'm happy with udpu for now.  This lets me focus on the other things that are acting oddly:</span></div>

<div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">Trying to add a monitor to a systemd: resource, like this:</span></div><div>
<span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">    pcs resource create httpd systemd:httpd op monitor interval=30s</span></div><div>
<span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">Which generates this in the cib:</span></div><div><span style="white-space:pre-wrap"><br>
</span></div><div><font color="#000000"><span style="white-space:pre-wrap">-- <cib admin_epoch="0" epoch="7" num_updates="25" />
++       <primitive class="systemd" id="httpd" type="httpd" >
++         <instance_attributes id="httpd-instance_attributes" />
++         <operations >
++           <op id="httpd-monitor-interval-30s" interval="30s" name="monitor" />
++         </operations>
++       </primitive>
</span></font><span style="white-space:pre-wrap">
</span></div><div><span style="white-space:pre-wrap">Results in the service never successfully starting:</span></div><div><span style="white-space:pre-wrap"><br></span></div>
<div><font color="#000000"><span style="white-space:pre-wrap">notice: process_lrm_event: LRM operation httpd_monitor_0 (call=10, rc=7, cib-update=30, confirmed=true) not running
notice: process_lrm_event: LRM operation httpd_start_0 (call=13, rc=0, cib-update=31, confirmed=true) ok
notice: process_lrm_event: LRM operation httpd_monitor_30000 (call=16, rc=7, cib-update=32, confirmed=false) not running
warning: status_from_rc: Action 11 (httpd_monitor_30000) on puppet0 failed (target: 0 vs. rc: 7): Error
warning: update_failcount: Updating failcount for httpd on puppet0 after failed monitor: rc=7 (update=value++, time=1361503742)
notice: run_graph: Transition 2 (Complete=7, Pending=0, Fired=0, Skipped=0, Incomplete=0, Source=/var/lib/pacemaker/pengine/pe-input-2278.bz2): Complete
notice: attrd_trigger_update: Sending flush op to all hosts for: fail-count-httpd (1)
notice: attrd_perform_update: Sent update 11: fail-count-httpd=1
notice: attrd_trigger_update: Sending flush op to all hosts for: last-failure-httpd (1361503742)
notice: attrd_perform_update: Sent update 14: last-failure-httpd=1361503742
warning: unpack_rsc_op: Processing failed op monitor for httpd on puppet0: not running (7)
notice: LogActions: Recover httpd#011(Started puppet0)
notice: process_pe_message: Calculated Transition 3: /var/lib/pacemaker/pengine/pe-input-2279.bz2
warning: unpack_rsc_op: Processing failed op monitor for httpd on puppet0: not running (7)
notice: LogActions: Recover httpd#011(Started puppet0)
notice: process_pe_message: Calculated Transition 4: /var/lib/pacemaker/pengine/pe-input-2280.bz2
warning: unpack_rsc_op: Processing failed op monitor for httpd on puppet0: not running (7)</span></font><span style="white-space:pre-wrap">
</span></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">This will continue until pacemaker declares the service FAILED, even though httpd (in this example) starts up manually (with "systemctl start httpd") without a problem. For what it's worth, the dbus method call to get the ActiveState property appears to work:</span></div>
<div><span style="white-space:pre-wrap"><br></span></div><div style><span style="white-space:pre-wrap">  # systemctl start httpd</span></div><div><span style="white-space:pre-wrap">  # </span><span style="white-space:pre-wrap">gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1/unit/httpd_2eservice -m org.freedesktop.DBus.Properties.Get org.freedesktop.systemd1.Unit ActiveState</span></div>
<div><span style="white-space:pre-wrap">(<'active'>,)
</span></div><div><span style="white-space:pre-wrap"><br></span></div></div></div></div>