>If you build from source, you can apply the patch that fixes the issue
>to the 1.1.14 code base:
>https://github.com/ClusterLabs/pacemaker/commit/98457d1635db1222f93599b6021e662e766ce62d
[1]
Just applied the patch and now it works as expected. The unseen node is
only rebooted once on startup
On Wed, 2018-09-05 at 17:21 +0200, Cesar Hernandez wrote:
> >
> > P.S. If the issue is just a matter of timing when you're starting
> > both
> > nodes, you can start corosync on both nodes first, then start
> > pacemaker
> > on both nodes. That way pacemaker on each node will immediately see
> > t
>
> P.S. If the issue is just a matter of timing when you're starting both
> nodes, you can start corosync on both nodes first, then start pacemaker
> on both nodes. That way pacemaker on each node will immediately see the
> other node's presence.
> --
Well rebooting a server lasts 2 minutes a
On Wed, 2018-09-05 at 09:51 -0500, Ken Gaillot wrote:
> On Wed, 2018-09-05 at 16:38 +0200, Cesar Hernandez wrote:
> > Hi
> >
> > >
> > > Ah, this rings a bell. Despite having fenced the node, the
> > > cluster
> > > still considers the node unseen. That was a regression in 1.1.14
> > > that
> > >
On Wed, 2018-09-05 at 16:38 +0200, Cesar Hernandez wrote:
> Hi
>
> >
> > Ah, this rings a bell. Despite having fenced the node, the cluster
> > still considers the node unseen. That was a regression in 1.1.14
> > that
> > was fixed in 1.1.15. :-(
> >
>
> Oh :( I'm using Pacemaker-1.1.14.
>
Hi
>
> Ah, this rings a bell. Despite having fenced the node, the cluster
> still considers the node unseen. That was a regression in 1.1.14 that
> was fixed in 1.1.15. :-(
>
Oh :( I'm using Pacemaker-1.1.14.
Do you know if this reboot retries are just run 3 times? All the tests I've
done
On Wed, 2018-09-05 at 13:31 +0200, Cesar Hernandez wrote:
> Hi
>
> >
> > The first fencing is legitimate -- the node hasn't been seen at
> > start-
> > up, and so needs to be fenced. The second fencing will be the one
> > of
> > interest. Also, look for the result of the first fencing.
>
> The f
Hi
>
> The first fencing is legitimate -- the node hasn't been seen at start-
> up, and so needs to be fenced. The second fencing will be the one of
> interest. Also, look for the result of the first fencing.
The first fencing has finished with OK, as well as the other two fencing
operations.
On Fri, 2018-08-31 at 08:37 +0200, Cesar Hernandez wrote:
> Hi
>
> >
> >
> > Do you mean you have a custom fencing agent configured? If so,
> > check
> > the return value of each attempt. Pacemaker should request fencing
> > only
> > once as long as it succeeds (returns 0), but if the agent fail
Hi
>
>
> Do you mean you have a custom fencing agent configured? If so, check
> the return value of each attempt. Pacemaker should request fencing only
> once as long as it succeeds (returns 0), but if the agent fails
> (returns nonzero or times out), it will retry, even if the reboot
> worked i
On Thu, 2018-08-30 at 17:24 +0200, Cesar Hernandez wrote:
> Hi
>
> I have a two-node corosync+pacemaker which, starting only one node,
> it fences the other node. It's ok as the default behaviour as the
> default "startup-fencing" is set to true.
> But, the other node is rebooted 3 times, and then
Hi
I have a two-node corosync+pacemaker which, starting only one node, it fences
the other node. It's ok as the default behaviour as the default
"startup-fencing" is set to true.
But, the other node is rebooted 3 times, and then, the remaining node starts
resources and doesn't fence the node an
12 matches
Mail list logo
