<div dir="ltr">I'm using version 1.1.15-11.el7_3.2-e174ec8. As far as I know the latest stable version in Centos 7.3<div><br></div><div>Gerard</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 18, 2017 at 4:42 PM, Ken Gaillot <span dir="ltr"><<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 2017-10-18 at 14:25 +0200, Gerard Garcia wrote:<br>
> So I think I found the problem. The two resources are named forwarder<br>
> and bgpforwarder. It doesn't matter if bgpforwarder exists. It is<br>
> just that when I set the failcount to INFINITY to a resource named<br>
> bgpforwarder (crm_failcount -r bgpforwarder -v INFINITY) it directly<br>
> affects the forwarder resource. <br>
><br>
> If I change the name to forwarderbgp, the problem disappears. So it<br>
> seems that the problem is that Pacemaker mixes the bgpforwarder and<br>
> forwarder names. Is it a bug?<br>
><br>
> Gerard<br>
<br>
</span>That's really surprising. What version of pacemaker are you using?<br>
There were a lot of changes in fail count handling in the last few<br>
releases.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Tue, Oct 17, 2017 at 6:27 PM, Gerard Garcia <<a href="mailto:gerard@talaia.io">gerard@talaia.io</a>><br>
> wrote:<br>
> > That makes sense. I've tried copying the anything resource and<br>
> > changed its name and id (which I guess should be enough to make<br>
> > pacemaker think they are different) but I still have the same<br>
> > problem.<br>
> ><br>
> > After more debugging I have reduced the problem to this:<br>
> > * First cloned resource running fine<br>
> > * Second cloned resource running fine<br>
> > * Manually set failcount to INFINITY to second cloned resource<br>
> > * Pacemaker triggers an stop operation (without monitor operation<br>
> > failing) for the two resources in the node where the failcount has<br>
> > been set to INFINITY.<br>
> > * Reset failcount starts the two resources again<br>
> ><br>
> > Weirdly enough the second resource doesn't stop if I set the the<br>
> > the first resource failcount to INFINITY (not even the first<br>
> > resource stops...). <br>
> ><br>
> > But:<br>
> > * If I set the first resource as globally-unique=true it does not<br>
> > stop so somehow this breaks the relation.<br>
> > * If I manually set the failcount to 0 in the first resource that<br>
> > also breaks the relation so it does not stop either. It seems like<br>
> > the failcount value is being inherited from the second resource<br>
> > when it does not have any value. <br>
> ><br>
> > I must have something wrongly configuration but I can't really see<br>
> > why there is this relationship...<br>
> ><br>
> > Gerard<br>
> ><br>
> > On Tue, Oct 17, 2017 at 3:35 PM, Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
> > wrote:<br>
> > > On Tue, 2017-10-17 at 11:47 +0200, Gerard Garcia wrote:<br>
> > > > Thanks Ken. Yes, inspecting the logs seems that the failcount<br>
> > > of the<br>
> > > > correctly running resource reaches the maximum number of<br>
> > > allowed<br>
> > > > failures and gets banned in all nodes.<br>
> > > ><br>
> > > > What is weird is that I just see how the failcount for the<br>
> > > first<br>
> > > > resource gets updated, is like the failcount are being mixed.<br>
> > > In<br>
> > > > fact, when the two resources get banned the only way I have to<br>
> > > make<br>
> > > > the first one start is to disable the failing one and clean the<br>
> > > > failcount of the two resources (it is not enough to only clean<br>
> > > the<br>
> > > > failcount of the first resource) does it make sense?<br>
> > > ><br>
> > > > Gerard<br>
> > ><br>
> > > My suspicion is that you have two instances of the same service,<br>
> > > and<br>
> > > the resource agent monitor is only checking the general service,<br>
> > > rather<br>
> > > than a specific instance of it, so the monitors on both of them<br>
> > > return<br>
> > > failure if either one is failing.<br>
> > ><br>
> > > That would make sense why you have to disable the failing<br>
> > > resource, so<br>
> > > its monitor stops running. I can't think of why you'd have to<br>
> > > clean its<br>
> > > failcount for the other one to start, though.<br>
> > ><br>
> > > The "anything" agent very often causes more problems than it<br>
> > > solves ...<br>
> > >  I'd recommend writing your own OCF agent tailored to your<br>
> > > service.<br>
> > > It's not much more complicated than an init script.<br>
> > ><br>
> > > > On Mon, Oct 16, 2017 at 6:57 PM, Ken Gaillot <kgaillot@redhat.c<br>
> > > om><br>
> > > > wrote:<br>
> > > > > On Mon, 2017-10-16 at 18:30 +0200, Gerard Garcia wrote:<br>
> > > > > > Hi,<br>
> > > > > ><br>
> > > > > > I have a cluster with two ocf:heartbeat:anything resources<br>
> > > each<br>
> > > > > one<br>
> > > > > > running as a clone in all nodes of the cluster. For some<br>
> > > reason<br>
> > > > > when<br>
> > > > > > one of them fails to start the other one stops. There is<br>
> > > not any<br>
> > > > > > constrain configured or any kind of relation between them. <br>
> > > > > ><br>
> > > > > > Is it possible that there is some kind of implicit relation<br>
> > > that<br>
> > > > > I'm<br>
> > > > > > not aware of (for example because they are the same type?)<br>
> > > > > ><br>
> > > > > > Thanks,<br>
> > > > > ><br>
> > > > > > Gerard<br>
> > > > ><br>
> > > > > There is no implicit relation on the Pacemaker side. However<br>
> > > if the<br>
> > > > > agent returns "failed" for both resources when either one<br>
> > > fails,<br>
> > > > > you<br>
> > > > > could see something like that. I'd look at the logs on the DC<br>
> > > and<br>
> > > > > see<br>
> > > > > why it decided to restart the second resource.<br>
> > > > > --<br>
> > > > > Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
> > > > ><br>
> > > > > ______________________________<wbr>_________________<br>
> > > > > Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> > > > > <a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
> > > > ><br>
> > > > > Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
> > > > > Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_</a><br>
> > > Scratc<br>
> > > > > h.pdf<br>
> > > > > Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
> > > > ><br>
> > > ><br>
> > > > ______________________________<wbr>_________________<br>
> > > > Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> > > > <a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
> > > ><br>
> > > > Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
> > > > Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Sc" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Sc</a><br>
> > > ratch.<br>
> > > > pdf<br>
> > > > Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
> > > --<br>
> > > Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
> > ><br>
> > > ______________________________<wbr>_________________<br>
> > > Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> > > <a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
> > ><br>
> > > Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
> > > Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scra" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scra</a><br>
> > > tch.pdf<br>
> > > Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
> > ><br>
> ><br>
> ><br>
><br>
> ______________________________<wbr>_________________<br>
> Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> <a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
><br>
> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
> Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch</a>.<br>
> pdf<br>
> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
--<br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
<br>
______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div>