<html><body><div style="color:#000; background-color:#fff; font-family:verdana, helvetica, sans-serif;font-size:10pt"><div><span>Yes I neither have stonith nor MCP configured. <br></span></div><div><span><br></span></div><div><span>I just changed the pacemaker version to 1 in the corosync.conf and tried the same thing.(i.e kill corosync). I still see the same issue as before. Is there anything else I need to do to enable the MCP?<br></span></div><div><br></div><div style="font-family: verdana,helvetica,sans-serif; font-size: 10pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font face="Arial" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Florian Haas <florian@hastexo.com><br><b><span style="font-weight: bold;">To:</span></b> The Pacemaker cluster resource manager <pacemaker@oss.clusterlabs.org><br><b><span style="font-weight: bold;">Sent:</span></b> Monday, 14 November 2011
6:22 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Pacemaker] killing corosync leaves crmd, stonithd, lrmd, cib and attrd to hog up the cpu<br></font><br>On 2011-11-14 13:18, Dan Frincu wrote:<br>> Hi,<br>> <br>> On Mon, Nov 14, 2011 at 1:32 PM, ihjaz Mohamed <<a ymailto="mailto:ihjazmohamed@yahoo.co.in" href="mailto:ihjazmohamed@yahoo.co.in">ihjazmohamed@yahoo.co.in</a>> wrote:<br>>> Hi All,<br>>> As part of some robustness test for my cluster, I tried killing the corosync<br>>> process using kill -9 <pid>. After this I see that the pacemakerd service is<br>>> stopped but the processes crmd, stonithd, lrmd, cib and attrd are still<br>>> running and are hogging up the cpu.<br>> <br>> I have seen this kind of testing before and I have to say I don't<br>> consider it the recommended way of testing the cluster stack's<br>> "robustness". Pacemaker processes rely on corosync
for proper<br>> functioning. You kill corosync and then want to "cleanup" the<br>> processes? You have to go through a lot more literature in order to<br>> understand how this cluster stack works.<br><br>Well I, for my part, don't consider this kind of testing unreasonable at<br>all. If Corosync dies, say due to a segfault, then the cluster had<br>better recover to a consistent state.<br><br>Thus, this (very valid) testing highlights that the cluster is evidently<br>misconfigured; it's either not using Pacemaker MCP at all, or doesn't<br>have STONITH configured, or neither.<br><br>Florian<br><br>-- <br>Need help with High Availability?<br><a href="http://www.hastexo.com/now" target="_blank">http://www.hastexo.com/now</a><br><br>_______________________________________________<br>Pacemaker mailing list: <a ymailto="mailto:Pacemaker@oss.clusterlabs.org" href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br><a
href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br><br>Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>Bugs: <a href="http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker" target="_blank">http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker</a><br><br><br></div></div></div></body></html>