[Glass] Monit scripts for gemstone?

Mariano Martinez Peck marianopeck at gmail.com
Wed Aug 20 06:58:27 PDT 2014

On Wed, Aug 20, 2014 at 5: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.
Yes, me too. Ok, so agree here.
But...I had yet another problem. Upon startup...no problem. But upon
shutdown, it seemed that monit was shutting down AFTER my init.d script.
Therefore...I was shutting down in init.d and monit was alive putting them
alive again. And that (I think), let me to strange situations. So I had to
change the priorities of my init script to be sure upon startup it runs
before monit and in shutdown, after.

You didn't have problems with this? Or maybe just by chance your
startup/shutdown order is like that?

> 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...
OK. I see.

> > 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...

What I did is in my init script I do:

case "$1" in
        printf "%-50s" "Starting $NAME..."
find /opt/gemstone/locks/ -type f -not -name 'gemstone.hostid' -delete
/bin/bash /opt/gemstoneAdditions/scripts/startStonesAll.sh
/bin/bash /opt/gemstoneAdditions/scripts/startSeasideGemsAll.sh

note the: find /opt/gemstone/locks/ -type f -not -name 'gemstone.hostid'

Why? Basically, I assume that if the system is starting, none process
should be alive, hence all locks files should be deleted.

Is this assumption safe?

In any case, I think this is a workaround. I would like to know why some
lock files are not being deleted. From what I understand, lock files should
always be removed, unless you do a kill -9 or something. And I am not doing


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140820/3feaccc0/attachment.html>

More information about the Glass mailing list