[Glass] Monit scripts for gemstone?
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Wed Feb 18 15:01:37 PST 2015
On Wed, Feb 18, 2015 at 7:07 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:
>
>
> On Thu, Dec 19, 2013 at 11:09 AM, Johan Brichau <johan at yesplan.be> wrote:
>
>> Hi Mariano,
>>
>> This is what I setup for each stone.
>> Change the file paths, the user/group names, fill in the TEMPLATE and
>> PORTxx stuff, adapt the timeouts to your need and you should be good to go.
>>
>> Johan
>>
>> #################################
>> ## TEMPLATE
>> #################################
>> check process fastcgi_PORT1_TEMPLATE with pidfile
>> /opt/gemstone/stones/TEMPLATE/data/FastCGI_server-PORT1.pid
>> start program = "/home/yesplan/yesplanscripts/startYesplanGems
>> TEMPLATE PORT1" as uid yesplan and gid yesplan
>> stop program = "/home/yesplan/yesplanscripts/stopYesplanGems
>> TEMPLATE PORT1" as uid yesplan and gid yesplan
>> DEPENDS on stone_TEMPLATE
>> GROUP TEMPLATE
>> # Empty FastCGI request
>> if failed port PORT1
>> # Send FastCGI packet: version 1 (0x01), cmd
>> FCGI_GET_VALUES (0x09)
>> # padding 8 bytes (0x08), followed by 8xNULLs padding
>> send
>> "\0x01\0x09\0x00\0x00\0x00\0x00\0x08\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00"
>> # Expect FastCGI packet: version 1 (0x01), resp
>> FCGI_GET_VALUES_RESULT (0x0A)
>> expect "\0x01\0x0A"
>> timeout 40 seconds
>> then restart
>>
>
>
> Hi Johan,
>
> Sorry for reviving this very old thread. But I have a doubt. Why do you do
> that special send / expect of the FastCGI protocol rather than a simple:
>
> if failed port PORT1 then restart
>
> Is this in case that the gem could be somehow "hanged" yet still having
> the port still open? Any other reason?
>
> I ask because I am experimenting something which I am not sure this is the
> expected behavior. Basically, what happens to me is that if the gem is up
> and alive, monit (when it checks the status of the process) will be waiting
> for those 40 seconds before continue checking the next process. Is this
> expect? It is happening the same to you?
>
> which timeout you have in your webserver for the upstreams? 40 seconds too?
>
>
Let me re-ask what is the more important question I have.... for that monit
timeout "timeout 40 seconds" I must setup a number like that, or exactly
the timeout I define at my web server. For example, I have loooong request
(yes, I know, I should be using service VM...but until then..), so my
timeout for the upstreams at nginx level is 5 minutes. So which timeout do
I need to set here? 5 minutes too? Or still 40 seconds?
I ask because I don't want the scenario where I am processing a long
request (imagine one of 4 minutes) and then monit after 40 seconds thinks
the server is down and hence triggers a restar. So I wonder...is the
FastCGI server able to answer the Monit send even if it is processing a
request? or the return to Monit will only be once it finishes processing
current request? That might tell me which timeout should I set here.
Thanks in advance!!
> Thanks in advance,
>
>
>
> Thanks in advance,
>
>
>
>
>> check process fastcgi_PORT2_TEMPLATE with pidfile
>> /opt/gemstone/stones/TEMPLATE/data/FastCGI_server-PORT2.pid
>> start program = "/home/yesplan/yesplanscripts/startYesplanGems
>> TEMPLATE PORT2" as uid yesplan and gid yesplan
>> stop program = "/home/yesplan/yesplanscripts/stopYesplanGems
>> TEMPLATE PORT2" as uid yesplan and gid yesplan
>> DEPENDS on stone_TEMPLATE
>> GROUP TEMPLATE
>> # Empty FastCGI request
>> if failed port PORT2
>> # Send FastCGI packet: version 1 (0x01), cmd
>> FCGI_GET_VALUES (0x09)
>> # padding 8 bytes (0x08), followed by 8xNULLs padding
>> send
>> "\0x01\0x09\0x00\0x00\0x00\0x00\0x08\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00"
>> # Expect FastCGI packet: version 1 (0x01), resp
>> FCGI_GET_VALUES_RESULT (0x0A)
>> expect "\0x01\0x0A"
>> timeout 40 seconds
>> then restart
>> check process fastcgi_PORT3_TEMPLATE with pidfile
>> /opt/gemstone/stones/TEMPLATE/data/FastCGI_server-PORT3.pid
>> start program = "/home/yesplan/yesplanscripts/startYesplanGems
>> TEMPLATE PORT3" as uid yesplan and gid yesplan
>> stop program = "/home/yesplan/yesplanscripts/stopYesplanGems
>> TEMPLATE PORT3" as uid yesplan and gid yesplan
>> DEPENDS on stone_TEMPLATE
>> GROUP TEMPLATE
>> # Empty FastCGI request
>> if failed port PORT3
>> # Send FastCGI packet: version 1 (0x01), cmd
>> FCGI_GET_VALUES (0x09)
>> # padding 8 bytes (0x08), followed by 8xNULLs padding
>> send
>> "\0x01\0x09\0x00\0x00\0x00\0x00\0x08\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00"
>> # Expect FastCGI packet: version 1 (0x01), resp
>> FCGI_GET_VALUES_RESULT (0x0A)
>> expect "\0x01\0x0A"
>> timeout 40 seconds
>> then restart
>> check process servicevm_TEMPLATE with pidfile
>> /opt/gemstone/stones/TEMPLATE/data/service.pid
>> start program =
>> "/home/yesplan/yesplanscripts/startYesplanServiceVM TEMPLATE" as uid
>> yesplan and gid yesplan
>> stop program = "/home/yesplan/yesplanscripts/stopYesplanServiceVM
>> TEMPLATE" as uid yesplan and gid yesplan
>> DEPENDS on stone_TEMPLATE
>> GROUP TEMPLATE
>> check file extent_TEMPLATE with path
>> /opt/gemstone/stones/TEMPLATE/data/extent0.dbf
>> if size > 4 GB then alert
>> GROUP TEMPLATE
>> check process stone_TEMPLATE with pidfile
>> /opt/gemstone/stones/TEMPLATE/data/TEMPLATE.pid
>> start program =
>> "/home/yesplan/yesplanscripts/startYesplanStone TEMPLATE" as uid yesplan
>> and gid yesplan
>> stop program =
>> "/home/yesplan/yesplanscripts/stopYesplanStone TEMPLATE" as uid yesplan and
>> gid yesplan
>> GROUP TEMPLATE
>>
>>
>> On 19 Dec 2013, at 15:03, Mariano Martinez Peck <marianopeck at gmail.com>
>> wrote:
>>
>> > Ok, I could start writing monit scripts for gemstone, but I guess many
>> people already did that, right?
>> >
>> > The thing is that there are many processes to monit: the stone, netldi,
>> each gem, etc.. From what I could see most of them, if not all, have a
>> place for the pid, so it could be easy to write the monit scripts. For the
>> seaside gems we could check the port.
>> >
>> > Thoughts?
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
>> > _______________________________________________
>> > Glass mailing list
>> > Glass at lists.gemtalksystems.com
>> > http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150218/79d8e8c5/attachment-0001.html>
More information about the Glass
mailing list