<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><br><br><pre>&gt;Another possibility would be to have the start return immediately, and
&gt;make the monitor artificially return success for the first 10 minutes
&gt;after starting. It's hacky, and it depends on your situation whether
&gt;the behavior is acceptable.</pre>

<div class="input-operate">
<a href="http://fanyi.baidu.com/###" class="operate-btn op-sound data-hover-tip" data-hover-tip-text="发音" style="display: block;">
</a>
<div class="op-favor-container">



</div>


</div>





          <span class="">I tried to put the sleep into the monitor function,( I add a “sleep 60” at the monitor entry for debug),&nbsp; the start function returns immediately.</span><span class=""> I found an interesting thing that is, at the first time of monitor after start, it will block other resource too, but </span> from the second time, it won't block other resources! Is this normal?<br><div><br><pre>&gt;My first thought on how to implement this
&gt;would be to have the start action set a private node attribute
&gt;(attrd_updater -p) with a timestamp. When the monitor runs, it could do
&gt;its usual check, and if it succeeds, remove that node attribute, but if
&gt;it fails, check the node attribute to see whether it's within the
&gt;desired delay.<br>This means that if it is in the desired delay, monitor should return success even if healthcheck failed?<br>I think this can solve my problem except "crm status" show<br><br></pre></div><br><div style="position:relative;zoom:1"></div><div id="divNeteaseMailCard"></div><pre><br>At 2017-11-01 21:20:50, "Ken Gaillot" &lt;kgaillot@redhat.com&gt; wrote:
&gt;On Sat, 2017-10-28 at 01:11 +0800, lkxjtu wrote:
&gt;&gt; 
&gt;&gt; Thank you for your response! This means that there shoudn't be long
&gt;&gt; "sleep" in ocf script.
&gt;&gt; If my service takes 10 minite from service starting to healthcheck
&gt;&gt; normally, then what shoud I do?
&gt;
&gt;That is a tough situation with no great answer.
&gt;
&gt;You can leave it as it is, and live with the delay. Note that it only
&gt;happens if a resource fails after the slow resource has already begun
&gt;starting ... if they fail at the same time (as with a node failure),
&gt;the cluster will schedule recovery for both at the same time.
&gt;
&gt;Another possibility would be to have the start return immediately, and
&gt;make the monitor artificially return success for the first 10 minutes
&gt;after starting. It's hacky, and it depends on your situation whether
&gt;the behavior is acceptable. My first thought on how to implement this
&gt;would be to have the start action set a private node attribute
&gt;(attrd_updater -p) with a timestamp. When the monitor runs, it could do
&gt;its usual check, and if it succeeds, remove that node attribute, but if
&gt;it fails, check the node attribute to see whether it's within the
&gt;desired delay.
&gt;
&gt;&gt; Thank you very much!
&gt;&gt; &nbsp;
&gt;&gt; &gt; Hi,
&gt;&gt; &gt; If I remember correctly, any pending actions from a previous
&gt;&gt; transition
&gt;&gt; &gt; must be completed before a new transition can be calculated.
&gt;&gt; Otherwise,
&gt;&gt; &gt; there's the possibility that the pending action could change the
&gt;&gt; state
&gt;&gt; &gt; in a way that makes the second transition's decisions harmful.
&gt;&gt; &gt; Theoretically (and ideally), pacemaker could figure out whether
&gt;&gt; some of
&gt;&gt; &gt; the actions in the second transition would be needed regardless of
&gt;&gt; &gt; whether the pending actions succeeded or failed, but in practice,
&gt;&gt; that
&gt;&gt; &gt; would be difficult to implement (and possibly take more time to
&gt;&gt; &gt; calculate than is desirable in a recovery situation).
&gt;&gt; &nbsp;
&gt;&gt; &gt; On Fri, 2017-10-27 at 23:54 +0800, lkxjtu wrote:
&gt;&gt; 
&gt;&gt; &gt; I have two clone resources in my corosync/pacemaker cluster. They
&gt;&gt; are
&gt;&gt; &gt; fm_mgt and logserver. Both of their RA is ocf. fm_mgt takes 1
&gt;&gt; minute
&gt;&gt; &gt; to start the
&gt;&gt; &gt; service(calling ocf start function for 1 minite). Configured as
&gt;&gt; &gt; below:
&gt;&gt; &gt; # crm configure show
&gt;&gt; &gt; node 168002177: 192.168.2.177
&gt;&gt; &gt; node 168002178: 192.168.2.178
&gt;&gt; &gt; node 168002179: 192.168.2.179
&gt;&gt; &gt; primitive fm_mgt fm_mgt \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; op monitor interval=20s timeout=120s \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; op stop interval=0 timeout=120s on-fail=restart \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; op start interval=0 timeout=120s on-fail=restart \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta target-role=Started
&gt;&gt; &gt; primitive logserver logserver \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; op monitor interval=20s timeout=120s \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; op stop interval=0 timeout=120s on-fail=restart \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; op start interval=0 timeout=120s on-fail=restart \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta target-role=Started
&gt;&gt; &gt; clone fm_mgt_replica fm_mgt
&gt;&gt; &gt; clone logserver_replica logserver
&gt;&gt; &gt; property cib-bootstrap-options: \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have-watchdog=false \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dc-version=1.1.13-10.el7-44eb2dd \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cluster-infrastructure=corosync \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stonith-enabled=false \
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; start-failure-is-fatal=false
&gt;&gt; &gt; When I kill fm_mgt service on one node,pacemaker will immediately
&gt;&gt; &gt; recover it after monitor failed. This looks perfectly normal. But
&gt;&gt; in
&gt;&gt; &gt; this 1 minite
&gt;&gt; &gt; of fm_mgt starting, if I kill logserver service on any node, the
&gt;&gt; &gt; monitor will catch the fail normally too,but pacemaker will not
&gt;&gt; &gt; restart it
&gt;&gt; &gt; immediately but waiting for fm_mgt starting finished. After fm_mgt
&gt;&gt; &gt; starting finished, pacemaker begin restarting logserver. It seems
&gt;&gt; &gt; that there are
&gt;&gt; &gt; some dependency between pacemaker resource.
&gt;&gt; &gt; # crm status
&gt;&gt; &gt; Last updated: Thu Oct 26 06:40:24 2017&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last change: Thu
&gt;&gt; Oct
&gt;&gt; &gt; 26&nbsp;&nbsp;&nbsp;&nbsp; 06:36:33 2017 by root via crm_resource on 192.168.2.177
&gt;&gt; &gt; Stack: corosync
&gt;&gt; &gt; Current DC: 192.168.2.179 (version 1.1.13-10.el7-44eb2dd) -
&gt;&gt; partition
&gt;&gt; &gt; with quorum
&gt;&gt; &gt; 3 nodes and 6 resources configured
&gt;&gt; &gt; Online: [ 192.168.2.177 192.168.2.178 192.168.2.179 ]
&gt;&gt; &gt; Full list of resources:
&gt;&gt; &gt;&nbsp; Clone Set: logserver_replica [logserver]
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; logserver&nbsp; (ocf::heartbeat:logserver):&nbsp;&nbsp;&nbsp;&nbsp; FAILED
&gt;&gt; 192.168.2.177
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Started: [ 192.168.2.178 192.168.2.179 ]
&gt;&gt; &gt;&nbsp; Clone Set: fm_mgt_replica [fm_mgt]
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Started: [ 192.168.2.178 192.168.2.179 ]
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stopped: [ 192.168.2.177 ]
&gt;&gt; &gt; I am confusing very much. Is there something wrong configure?Thank
&gt;&gt; &gt; you very much!
&gt;&gt; &gt; James
&gt;&gt; &gt; best regards
&gt;&gt; &nbsp;
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 【网易自营】好吃到爆!鲜香弹滑加热即食,经典13香/麻辣小龙虾仅75元3斤&gt;&gt; &nbsp; &nbsp; &nbsp;
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 【网易自营】好吃到爆!鲜香弹滑加热即食,经典13香/麻辣小龙虾仅75元3斤&gt;&gt; &nbsp; &nbsp; &nbsp;
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 【网易自营|30天无忧退货】仅售同款价1/4!MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元&gt;&gt; &nbsp; &nbsp; &nbsp;
&gt;-- 
&gt;Ken Gaillot &lt;kgaillot@redhat.com&gt;
</pre></div><br><br><span title="neteasefooter"><p>&nbsp;</p></span>