<div dir="ltr">Thanks. In the end, I found out that my target application has a setting whereby the application becomes instantly detectable to the monitoring side of my script. After doing this, the associated resource is created flawlessly every time.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 1:46 PM Jan Pokorný <<a href="mailto:jpokorny@redhat.com">jpokorny@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">[letter-casing wise:<br>
 it's either "Pacemaker" or down-to-the-terminal "pacemaker"]<br>
<br>
On 16/04/19 10:21 -0600, JCA wrote:<br>
> 2. It would seem that what Pacemaker is doing is the following:<br>
>    a. Check out whether the app is running.<br>
>    b. If it is not, launch it.<br>
>    c. Check out again<br>
>    d. If running, exit.<br>
>    e. Otherwise, stop it.<br>
>     f. Launch it.<br>
>    g. Go to a.<br>
> <br>
> [...]<br>
> <br>
> 4. If the above is correct, and if I am getting the picture correctly, it<br>
> would seem that the problem is that my monitoring function does not detect<br>
> immediately that my app is up and running. That's clearly my problem.<br>
> However, is there any way to get Pacemaker to introduce a delay between<br>
> steps b and c in section 2 above?<br>
<br>
Ah, it should have occurred to me!<br>
<br>
Typical solution, I think, is to have a sleep loop following the<br>
daemon launch within "start" action that will run (subset) of what<br>
"monitor" normally does, so as to synchronize on the "service ready"<br>
moment.  Default timeout for "start" within agent's metadata should<br>
then reflect the common time to get to the point "monitor" is happy<br>
plus some reserve.<br>
<br>
Some agents may do more elaborate things like precisely limiting such<br>
waiting in respect to the time they were actually given by the<br>
resource manager/pacemaker (if I don't misremember, that value is<br>
provided through environment variables for sort of an introspection).<br>
<br>
Resource agent experts could advise here.<br>
<br>
(Truth to be told, "daemon readiness" used to be a very marginalized<br>
problem putting barriers to practical [= race-free] dependency ordering<br>
etc., luckily clever people realized that the most precize tracking<br>
can only be at the hands of the actual daemon implementors if event<br>
driven paradigm is to be applied.  For instance, if you can influence<br>
my_app, and it's a standard forking daemon, it would be best if the<br>
parent exited only when the daemon is truly ready to provide service<br>
-- this usually requires some typically signal-based synchronization<br>
amongst the daemon processes.  With systemd, situation is much simpler<br>
since no forking is necessary, just a call to sd_notify(3) -- in that<br>
case, though, your agent would need to mimic the server side of the<br>
sd_notify protocol since nothing would do it for you.)<br>
<br>
> 5. Following up on 4: if my script sleeps for a few seconds immediately<br>
> after launching my app (it's a daemon) in myapp_start then everything works<br>
> fine. Indeed, the call sequence in node one now becomes:<br>
> <br>
>          monitor:<br>
> <br>
>     Status: NOT_RUNNING<br>
>     Exit: NOT_RUNNING<br>
> <br>
>           start:<br>
> <br>
>     Validate: SUCCESS<br>
>     Status: NOT_RUNNING<br>
>     Start: SUCCESS<br>
>     Exit: SUCCESS<br>
> <br>
>           monitor:<br>
> <br>
>     Status: SUCCESS<br>
>     Exit: SUCCESS<br>
<br>
That's easier but less effective and reliable (more opportunistic than<br>
fact-based) than polling the "monitor" outcomes privately within "start"<br>
as sketched above.<br>
<br>
-- <br>
Jan (Poki)<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>