[Glass] Ways to auto start Seaside gems upon stone startup
Locked
[Glass] Ways to auto start Seaside gems upon stone startup
 
|
Hi guys,
I am using the tools from Norbert Halt to create stones. He makes an easy V script that you can put in /etc/init.d and then make it autostart/stop during OS start/stop. But that script simply start/stops the stone. I want my seaside gems to also be started.
I wonder what you do to auto start seaside gems after stone has started. 1) I saw SystemLoginNotification but I need to register a class. I would like to simply add a piece of code (that start seaside gems) and not a class.
2) I saw UserProfile>>loginHook:. But I don't understand how this or the previous one could help. Why? Because at OS startup I would only start the stone.. no user would be logged in. And if I would need to manually log in ...then I am in the same situation.
3) Modify the V script and also run the code to start my gems. I don't like this because I may want to only start the stone at some point.
4) Add ANOTHER V script that starts seaside gems... and make sure this one is executed AFTER the script to start stone 5) Write monit scripts which I wanted anyway and reuse the fact that monit would start upon system startup and would start gems because they are down ;)
I guess my best option is the last one right? or am I missing other alternatives? Thanks, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Ways to auto start Seaside gems upon stone startup
|
|
My solution is a combination:
- stones are started at startup using SYS V scripts - gems are started using monit, which is also started automatically I have bad experiences trying to start all things using monit. Although it allows to declare dependencies, it just does not try to start the stone first before starting the gems. In the end, if monit has execution failures starting gems, it will give up and you have to login manually anyway. Johan On 28 Jan 2014, at 19:47, Mariano Martinez Peck <[hidden email]> wrote: > Hi guys, > > I am using the tools from Norbert Halt to create stones. He makes an easy V script that you can put in /etc/init.d and then make it autostart/stop during OS start/stop. But that script simply start/stops the stone. I want my seaside gems to also be started. > > I wonder what you do to auto start seaside gems after stone has started. > > 1) I saw SystemLoginNotification but I need to register a class. I would like to simply add a piece of code (that start seaside gems) and not a class. > > 2) I saw UserProfile>>loginHook:. But I don't understand how this or the previous one could help. Why? Because at OS startup I would only start the stone.. no user would be logged in. And if I would need to manually log in ...then I am in the same situation. > > 3) Modify the V script and also run the code to start my gems. I don't like this because I may want to only start the stone at some point. > > 4) Add ANOTHER V script that starts seaside gems... and make sure this one is executed AFTER the script to start stone > > 5) Write monit scripts which I wanted anyway and reuse the fact that monit would start upon system startup and would start gems because they are down ;) > > I guess my best option is the last one right? or am I missing other alternatives? > > Thanks, > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Ways to auto start Seaside gems upon stone startup
|
|
In reply to this post by Mariano Martinez Peck
Option 5 is a good bet for managing gems ... I use daemontools[1],[2] for starting/auto starting the seaside gems up on SS3. I use monit to alert me if the gems/stone goes down for some reason and to also monitor disk space, etc.
The nice thing about daemontools is that they will restart a gem almost instantaneously... something that I'm not sure monit will do ... On Tue, Jan 28, 2014 at 10:47 AM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Ways to auto start Seaside gems upon stone startup
|
|
In reply to this post by Mariano Martinez Peck
On 01/28/2014 10:47 AM, Mariano Martinez Peck wrote:
> Hi guys, > > I am using the tools from Norbert Halt to create stones. He makes an > easy V script that you can put in /etc/init.d and then make it > autostart/stop during OS start/stop. But that script simply start/stops > the stone. I want my seaside gems to also be started. > > I wonder what you do to auto start seaside gems after stone has started. > I'd probably use a second init script to start the gems. It varies by distro, but there's usually some way to declare the ordering or dependencies of those scripts. Some, it's as simple as "they execute in alphabetical order". Regards, -Martin _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Ways to auto start Seaside gems upon stone startup
|
|
In reply to this post by Mariano Martinez Peck
Am 28.01.2014 um 19:47 schrieb Mariano Martinez Peck <[hidden email]>: I do No. #5. As you are using the stone-creator you could steal some things from here. First I do for every instance I want to run a monit script check process concierge-6100 with pidfile /var/tmp/concierge-6100.pid start = "/opt/application/bin/start-gem concierge 6100" as uid gemstone stop = "/opt/application/bin/stop-gem concierge 6100" # Empty FastCGI request if failed port 6100 # 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 5 seconds then restart This starts one web gem on port 6100 for user gemstone and checks the fast cgi behaviour every minute. If somethings goes wrong the gem is restarted. The next script is a bridge between the monit script and the gem startup script that uses the stone creator env (that is the /opt/application/bin/start-gem script) #!/bin/bash if [ "$2" == "" ]; then echo "usage. $0 [stone name] [port]" exit 1 fi echo $$ > /var/tmp/$1-$2.pid source /opt/application/$1/env source /opt/application/$1/etc/gem.conf export GEMSTONE_USER=DataCurator export GEMSTONE_PASSWORD=swordfish export GEMSTONE_NAME=$1 export TEMPORARY_OBJECT_MEMORY=$GEM_TEMPOBJ_CACHE_SIZE export LOGFILE=/opt/application/$1/log/$1-$2.log exec /opt/application/bin/gs-start-gem $1 $2 Here the pid file is created (we can use the current PID because I use exec at the end). Furthermore the env script from stone-creator is sourced to direct towards the right stone. The last script called is a modified version from the gemstone installation. IIRC it is only two lines exchanged. Here it is #!/bin/bash # # ./startSeaside30_Adaptor runs a Seaside server Gem the class WAGemStoneRunSeasideGems # determines whether a FastCGI, Swazoo or Zinc adaptor is used # - first argument is a label used to name files # - second argument is a port number # if [ -s $GEMSTONE/seaside/etc/gemstone.secret ]; then . $GEMSTONE/seaside/etc/gemstone.secret else echo 'Missing password file $GEMSTONE/seaside/etc/gemstone.secret' exit 1 fi # Requires a server type label as a parameter if [ "a$1" = "a" ]; then echo 'Missing argument <server type label>' exit 1 fi # Requires a port number as a parameter if [ "a$2" = "a" ]; then echo 'Missing argument <server port number>' exit 1 fi exec $GEMSTONE/bin/topaz -l -e $GEMSTONE/seaside/etc/seaside30.conf >> $GEMSTONE_LOGDIR/${1}_server-${2}.log 2>&1 << EOF set user DataCurator pass $GEMSTONE_PASSWORD gems $GEMSTONE_NAME display oops iferror where login run "record gems pid in the pid file" | file | (GsFile isServerDirectory: '$GEMSTONE_DATADIR') ifFalse: [ ^nil ]. file := GsFile openWriteOnServer: '$GEMSTONE_DATADIR/${1}_server-${2}.pid'. file nextPutAll: (System gemVersionReport at: 'processId') printString. file cr. file close. % run | x | "set _cacheName: for Gem to get unique id in statmon output. see http://code.google.com/p/glassdb/issues/detail?id=132" System _cacheName: ((x := '$1-' , (GsSession serialOfSession: System session) printString , '-' , System myUserProfile userId) copyFrom: 1 to: (x size min: 31)). % run GsProcess usingNativeCode not ifTrue: [ "Enable remote Breakpoing handling" Breakpoint trappable: true. GemToGemAnnouncement installStaticHandler. System commitTransaction ifFalse: [ nil error: 'Could not commit for GemToGemSignaling' ]. ]. System transactionMode: #manualBegin. Exception installStaticException: [:ex :cat :num :args | "Run the abort in a lowPriority process, since we must acquire the transactionMutex." [ GRPlatform current transactionMutex critical: [ GRPlatform current doAbortTransaction ]. System enableSignaledAbortError. ] forkAt: Processor lowestPriority. ] category: GemStoneError number: 6009 subtype: nil. System enableSignaledAbortError. "This thread is needed to handle the SigAbort exception, when the primary thread is blocked on an accept. Assuming default 60 second STN_GEM_ABORT_TIMEOUT, wake up at 30 second intervals." [ [ true ] whileTrue: [ (Delay forSeconds: 30) wait ]. ] forkAt: Processor lowestPriority. GsFile gciLogServer: '$1 Server started on port ', $2 printString. WAGemStoneRunSeasideGems startGemServerOn: $2. "does not return" % run GemToGemAnnouncement uninstallStaticHandler. System beginTransaction. (ObjectLogEntry fatal: '$1: topaz exit' object: 'port: ', $2 printString, ' ', 'pid: ', (System gemVersionReport at: 'processId') printString) addToLog. System commitTransaction. % EOF Hope that helps, Norbert _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Ways to auto start Seaside gems upon stone startup
|
|
In reply to this post by Johan Brichau-3
There is the waitstone command that ships with GemStone which you can use in your daemontools/monit scripts that will wait on the stone to be present before starting the gem. E.g.
#!/bin/bash source /opt/gemstone/product/seaside/defSeaside $GEMSTONE/bin/waitstone $GEMSTONE_NAME 2 exec setuidgid deploy $GEMSTONE/seaside/bin/startServiceVM31
|
|
|
Hi!
I tried to use the VSD tool but I seem to have some trouble with the resolution or font definitions on my Ubuntu installation. The drop down menues do not properly display their content. The entries overlap each other. Is there anything that I might be missing? Thanks Sebastian _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] VSD tool Ubuntu 12.04
|
|
I will check around ... On Tue, Jan 28, 2014 at 3:35 PM, Sebastian Heidbrink <[hidden email]> wrote: Hi! _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] VSD tool Ubuntu 12.04
|
|
No need, too! Thank you Dale!
Richard provided me already with the solution! One needs to change the font settings in VSD :-D "Chart -> Choose Chart Font" How embarrassing! Thank you again! Sebastian m 28.01.2014 16:03, schrieb Dale Henrichs:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |