<div dir="ltr">Hi I didn't manage to start master with postgres, even if I increased start timeout. I checked executable paths and start options.<br>When cluster is running with manually started master and slave started over pacemaker, everything works ok. Today we had failover again.<br>I cannot find reason from the logs, can you help me with debugging? Thanks.<br><br>Jul 09 09:16:34 [2681] postgres1  pengine:  warning: unpack_rsc_op_failure:     Processing failed op monitor for PGSQL:0 on postgres1: unknown error (1)<br><div>-</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 16 May 2019 at 17:12, Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2019-05-16 at 10:20 +0200, Jehan-Guillaume de Rorthais wrote:<br>
> On Wed, 15 May 2019 16:53:48 -0500<br>
> Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>> wrote:<br>
> <br>
> > On Wed, 2019-05-15 at 11:50 +0200, Jehan-Guillaume de Rorthais<br>
> > wrote:<br>
> > > On Mon, 29 Apr 2019 19:59:49 +0300<br>
> > > Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>> wrote:<br>
> > >   <br>
> > > > 29.04.2019 18:05, Ken Gaillot пишет:  <br>
> > > > > >    <br>
> > > > > > > Why does not it check OCF_RESKEY_CRM_meta_notify?    <br>
> > > > > > <br>
> > > > > > I was just not aware of this env variable. Sadly, it is not<br>
> > > > > > documented<br>
> > > > > > anywhere :(    <br>
> > > > > <br>
> > > > > It's not a Pacemaker-created value like the other notify<br>
> > > > > variables --<br>
> > > > > all user-specified meta-attributes are passed that way. We do<br>
> > > > > need to<br>
> > > > > document that.    <br>
> > > > <br>
> > > > OCF_RESKEY_CRM_meta_notify is passed also when "notify" meta-<br>
> > > > attribute<br>
> > > > is *not* specified, as well as a couple of others. But not<br>
> > > > all   <br>
> > <br>
> > Hopefully in that case it's passed as false? I vaguely remember<br>
> > some<br>
> > case where clone attributes were mistakenly passed to non-clone<br>
> > resources, but I think notify is always accurate for clone<br>
> > resources.<br>
> <br>
> [1]<br>
> <br>
> > > > possible<br>
> > > > attributes. And some OCF_RESKEY_CRM_meta_* variables that are<br>
> > > > passed do<br>
> > > > not correspond to any user settable and documented meta-<br>
> > > > attribute,<br>
> > > > like<br>
> > > > OCF_RESKEY_CRM_meta_clone.  <br>
> > > <br>
> > > Sorry guys, now I am confused.  <br>
> > <br>
> > A well-known side effect of pacemaker ;)<br>
> > <br>
> > > Is it safe or not to use OCF_RESKEY_CRM_meta_notify? You both<br>
> > > doesn't<br>
> > > seem to<br>
> > > agree where it comes from. Is it only a non expected side effect<br>
> > > or<br>
> > > is it safe<br>
> > > and stable code path in Pacemaker we can rely on?  <br>
> > <br>
> > It's reliable. All user-specified meta-attributes end up as<br>
> > environment<br>
> > variables <br>
> <br>
> OK...<br>
> <br>
> > -- it's just meta-attributes that *aren't* specified by the<br>
> > user that may or may not show up<br>
> <br>
> OK...<br>
> <br>
> > (but hopefully with the correct value).<br>
> <br>
> And that's where I am now loosing some confidence about this<br>
> environment vars :)<br>
> "Hopefully" and "I think is accurate" ([1]) are quite scary to me :/<br>
<br>
It looks perfectly reliable to me :) but Andrei's comments make me want<br>
more information.<br>
<br>
If I understand correctly, he's saying that the presence of the notify<br>
variable is unreliable. That's fine if the option is not specified by<br>
the user, and the variable is either not present or present as false.<br>
But it would indicate a bug if the variable is not present when the<br>
option *is* specified by the user, or if the variable is present as<br>
true when the option is not specified by the user.<br>
<br>
Personally I'd rely on it.<br>
<br>
The controller gets the environment variable values from the<br>
<attributes> entries in the scheduler's result. We have numerous<br>
examples in the scheduler regression test data, typically installed<br>
under /usr/share/pacemaker/tests in scheduler/*.exp (for 2.0) or<br>
pengine/test10/*.exp (for 1.1).<br>
-- <br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>><br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_4015929455341004419gmail_signature">Pozdrav<br>Danka Ivanovic</div>