[ClusterLabs] Antw: Delayed first monitoring

[Miloš Kozák]

Dne 13.8.2015 v 09:26 Andrei Borzenkov napsal(a):
> On Thu, Aug 13, 2015 at 10:01 AM, Miloš Kozák <milos.kozak at lejmr.com> wrote:
>> However,
>>   this does not make sense at all. Presumably, the pacemaker should get along
>> with lsb scripts which comes from system repository, right?
>>
> Let's forget about pacemaker for a moment. You have system startup
> where service B needs service A. initscript for service A completes
> and script for service B is started but service A is not yet ready to
> be used.
>
> This is a bug in startup script. Irrespectively of whether you use it
> with pacemaker or not.

I am sorry, but I didnt get the point..

If service A is not ready then service B should not be started. 
Presumably, the start mechanism of service A should not hold CLI, but 
something like pacemaker should check whether service A is ready and 
then start service B in case order constraint is applied. Therefore, I 
think I can not forget about pacemaker not even for a moment..

I agree that systemd changes this, but I run CentOS6 for the time being.

>> Therefore, there is not way how to modify lsb script because changes is lsb
>> script erase after every package update.
>>
>>
>> I believe, the systematical approach is in introducing of delayed monitoring
>> or something like this into Pacemaker. I quite wonder that nobody has come
>> around this problem already?
>>
>>
>> Milos
>>
>>
>>
>>
>>
>> Dne 13.8.2015 v 08:44 Ulrich Windl napsal(a):
>>
>>> I think the start script has to be fixed to return success when httpd is
>>> actually running.
>>>
>>>>>> Miloš Kozák <milos.kozak at lejmr.com> schrieb am 12.08.2015 um 16:03 in
>>> Nachricht
>>> <55CB521A.8090304 at lejmr.com>:
>>>> Hi,
>>>>
>>>> I have set up and CoroSync+CMAN+Pacemaker at CentOS 6.5 in order to
>>>> provide high-availability of opennebula. However, I am facing to a
>>>> strange problem which raises from my lack of knowleadge..
>>>>
>>>> In the log I can see that when I create a resource based on an init
>>>> script, typically:
>>>>
>>>> pcs resource create httpd lsb:httpd
>>>>
>>>> The httpd daemon gets started, but monitor is initiated at the same time
>>>> and the resource is identified as not running. This behaviour makes
>>>> sense since we realize that the daemon starting takes some time. In this
>>>> particular case, I get error code 2 which means that process is running,
>>>> but environment is not locked. The effect of this is that httpd resource
>>>> gets restarted.
>>>>
>>>> My workaround is extra sleep in status function of the init script, but
>>>> I dont like this solution at all! Do you have idea how to tackle this
>>>> problem in a proper way? I expected an op attribut which would specify
>>>> delay after service start and first monitoring, but I could not find it..
>>>>
>>>> Thank you, Milos
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list: Users at clusterlabs.org
>>>> http://clusterlabs.org/mailman/listinfo/users
>>>>
>>>> Project Home: http://www.clusterlabs.org
>>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>> Bugs: http://bugs.clusterlabs.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org
>>> http://clusterlabs.org/mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>
>>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org
>> http://clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org