initV script [was] Re: Is anyone using upstart to launch stones via tODE?
Locked
initV script [was] Re: Is anyone using upstart to launch stones via tODE?
 
|
Hi Jupiter,
You can find attached my initV script (it's actually a very very simple). While i think it would be nice to have template scripts in gsDevKit, I think that each user/app is different and may need slightly different scripts. So basically, I would consider these scripts as "examples" so where people can take a look to examples. Maybe someone will use them right ahead, others will likely take those as a base and make your own, etc. Here are some notes that I would like to say about my initV script (and in general): 1) Ideally, I put the initV file inside the directory of my stones and then put a symlink to /etc/init.d. That way, the init file can be self contained and even managed by the same source versioning system of the rest of your system. 2) It will change wether you want to start one stone or many. In this example I attach, I start/stop only one, but for real I have multiple. And I start/stop all of them from the same init file. One way to solve this would be a simply array in bash with all stone names and an for loop (or copy paste one line per stone). Another possibility which could be better is to define your own script, say $GS_HOME/sys/local/bin/startAllStones.sh which receives a list of stone names (Dale, would this directory be the best place for this?). And so that script can do the loop and call `startStone`. Same for stop. Actually, it would be nice if these could be part of GsDevKit_home. Dale? Another approach is for you to have an init file per stone... If you do this, you can adjust my attached file so that it received another argument which is the stone name. That way can can directly call `startStone` with that name and you also know which `gslist` to use :) If you do this, let the bash file of the init very very simple. I mean, an init file that could simply call the other one passing a stone via argument. You understand what I mean? Something like /etc/init.d/stoneXXX #!/bin/bash # Gemstone manager for StoneXXX # chkconfig: 345 96 01 # description: This is an init file for starting and stoping all stones. Monit is 98, so we want to start before. # processname: Gemstone manager /bin/bash $GS_HOME/local/bin/initVStone $1 stoneXXX 3) The `status` part can be implemented if you have only one GemStone. And anyway, if many, I think that gslist doesn't change much and that we could rely on the latest one. I guess having different gemstone installations is not THAT uncommon. 4) The `find` you see in my initV is because "gslist -c" did not work. But that was long ago. Maybe it works better now (I would try this first). We still have the same issue of which gslist to use. You can try to kill -9 stoneXX , then call "gslist -c" and see if the locks are still around. 5) The last issue I had which was a bit complicated and hacky to solve is the fact of having both, monit and initV. Basically, 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. This is why the special line "345 96 01". Let me know what do you think. I would like to know your thoughts on this so that we can come to a good example :) Best, On Tue, Nov 24, 2015 at 6:23 PM, Jupiter Jones <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
initGemstoneGsDevKit.sh (1K) | Free forum by Nabble | Edit this page |