+++ This bug was initially created as a clone of Bug #1395477 +++

--- Additional comment from Ken Gaillot on 2016-11-17 11:50:01 EST ---

(In reply to vlad.socaciu from comment #5)
> Yes, indeed, this is precisely what happens: "the agent is returning from
> the start once the relevant process has been started, but it has some
> start-up time before it is ready to handle requests".
> 
> However!!!, I thought that this situation would be handled by the cluster,
> if we set the value of "op start timeout" sufficiently high, which we did
> (timeout=45s). The documentation seems to indicate that this is the solution
> in case the lsb resource may take a longer time to respond to the "status"
> request:
> 
> "If you find that your system includes a resource that takes a long time to
> start or stop or perform a non-recurring monitor action at startup, and
> requires more time than the system allows before declaring that the start
> action has failed, you can increase this value from the default of 20 or the
> value of timeout in "op defaults"". (6.6 Resource Operation)
> 
> My interpretation of this text is that the cluster software should issue
> "monitor" commands to the resource for 45s, every "op monitor interval"
> seconds ("op monitor interval" was set to 10s in our case, I believe). 
> 
> I don't think that the cluster software should check the resource just once
> in the same second after it started it, and irrevocably declare that the
> resource is "not running" -- this seems to contradict 6.6 from the manual.
> But maybe the cluster developers' expectation was that the resource agent
> would block until it is ready to give a definitive response to the "status"
> command. In this case, the manual is vague and incomplete in explaining what
> the resource agent is expected to do at startup.

I can see how the manual could be confusing, so I'll look into clarifying it.

Yes, the cluster expects that monitor should return OK immediately after start returns OK. The start timeout is not the time until the first monitor, but the time given for the start itself to complete and return success or failure. If the start does not complete in that time, its process is killed, and it is considered failed. If the start completes before the timeout, the remaining timeout is ignored, and a monitor may immediately be done.