[Glass] Monit scripts for gemstone?

[Mariano Martinez Peck]

Ohh and I have yet another question. At night, I have some scripts that run
for GC , backups, and other stuff. For this, what I do is to stop all
seaside gems so that I don't get gslocks or waiting for vote or whatever
during MFC or the other tasks. So at the very beginning I turn off seaside
gems, and then, once I am done with everything, I start them again.

Of course, now with monit it could happen that monit starts again the
seaside gems I turned off. So, what do you do?

I was thinking to execute:

sudo monit unmonitor xxxx

where xxxx is every name of every monit file (one per stone)...

Shutting down monit is also an option but maybe too much.

Thoughts?



On Wed, Aug 20, 2014 at 11:02 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
>
> On Wed, Aug 20, 2014 at 7:56 AM, James Foster <
> james.foster at gemtalksystems.com> wrote:
>
>> The presence of lock files will prevent processes from starting, so they
>> might need to be cleared. They can be cleared by gslist with the ‘-c’
>> option and/or you could clear them as part of an init.d script at system
>> boot time. Obviously, they should not be always cleared as part of a
>> general start-up script since this would defeat the purpose,
>
>
> mmmm why?  I do run it always in my init.t script as part of my startup.
> See my other answer to Johan.
> Is my assumption wrong?
>
>
>> though a ‘gslist -c’ could be done anytime (my environments typically
>> have an alias for gslist=‘gslist -clv’).
>>
>>
> I tried that yesterday in my server when I had these lock files of dead
> process, and gslist -c did nothing. It simply displayed the stones and it
> didn't delete anything from /opt/gemstone/locks and I am sure the processes
> associated to those locks are dead.
>
> Thanks
>
>
>
>> James
>>
>> On Aug 20, 2014, at 4:17 AM, Johan Brichau <johan at yesplan.be> wrote:
>>
>> > On 20 Aug 2014, at 06:11, Mariano Martinez Peck <marianopeck at gmail.com>
>> wrote:
>> >
>> >> So...before everything...are you using init.d to start your stones as
>> well? or you let monit do it lazily?
>> >
>> > In case of reboot, I have found that monit does not work well to get
>> everything up and running fast.
>> > So, yes, I am using init.d to start all stones and gems.
>> >
>> >> if the later...how do you handle a proper shutdown? it happens to me
>> that some lock files remind alive but the process are gone. So upon reboot,
>> I cannot start my process again.
>> >
>> > Yes, I do recall that this happened but I have contradicting
>> experiences. On my laptop I often need to remove the lock files when they
>> are present. In contrast, last june all our servers got rebooted because of
>> a SAN network problem and there were no issues with the lock files. Maybe
>> someone from GemTalk can shed more light on that...
>> >
>> >> In summary.... I am having problems with locks file in
>> /opt/gemstone/locks and the presence of both, init.d and monit scripts.
>> >>
>> >> I can explain with more details what I am doing exactly, but just
>> wanted to know what you were doing.
>> >
>> > At the moment, I'm not doing anything automated with the lock files.
>> > If there is an issue starting a stone, it is one of the things I look
>> at but I don't have an automated strategy for handling them.
>> >
>> > It would be great to know and develop a common strategy for everyone to
>> follow...
>> >
>> > Johan
>> > _______________________________________________
>> > 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/20140820/0386d450/attachment.html>