Gem go down for WAFileLibrary error
Locked
12
12
Gem go down for WAFileLibrary error
 
|
Ciao,
i work with Gemstone 3.1.0.2 but i remember the same problem in hold version. When the system answer a request relative to a WAFileLibrary subclass and one specific method for example: > styleBaseCss > > self halt. > > ^' > /* CSS DTR Personalizzazioni */ > /* *** DTR thought, designed and developed by Dario Trussardi Romano *** */ > .colorBaseSctLcn{ > color: green; > } erase an error the GEM go down. After three web request the environment is inaccessible ( all based GEM is down ) Thank, Dario P.S. How i can restart in automatic the gem when it go down ? There is a script that handles this issue on Ubuntu system? |
Re: Gem go down for WAFileLibrary error
|
|
Dario,
First ... is the #halt causing your problem? I ask because if you are using a WAGemStoneProductionErrorHandler for Seaside then all halts, breakpoints and errors should be caught, added to the objectLog and an error message presented to the user ... the WAGemStoneProductionErrorHandler doesn't prevent a gem from going down due to out-of-memory or a handfull of other issues, but the run of the mill errors and halts should be caught .... I do recommend that you arrange to have gems automatically restarted when they die and for ss3 I use daemontools[1] ... it's a bit of a pain to set up, but works well once you get it going ... I assume that their are other solutions out there and I'm curious what other folks might use. Dale [1] http://code.google.com/p/glassdb/wiki/GLASSDaemonTools ----- Original Message ----- | From: "Dario Trussardi" <[hidden email]> | To: "beta discussion Gemstone Seaside" <[hidden email]> | Sent: Thursday, March 14, 2013 3:21:48 AM | Subject: [GS/SS Beta] Gem go down for WAFileLibrary error | | Ciao, | | i work with Gemstone 3.1.0.2 but i remember the same problem in hold | version. | | | When the system answer a request relative to a WAFileLibrary subclass | | and one specific method for example: | | > styleBaseCss | > | > self halt. | > | > ^' | > /* CSS DTR Personalizzazioni */ | > /* *** DTR thought, designed and developed by Dario Trussardi Romano *** | > */ | > .colorBaseSctLcn{ | > color: green; | > } | | erase an error the GEM go down. | | After three web request the environment is inaccessible ( all based GEM is | down ) | | Thank, | | Dario | | | P.S. How i can restart in automatic the gem when it go down ? | | There is a script that handles this issue on Ubuntu system? |
Re: Gem go down for WAFileLibrary error
|
|
Ciao Dale, the halt is only for understand. I can create a styleBaseCss with dynamic code ( it's not elegant ? ) ant it can go into error. Thanks, Dario > Dario, > > First ... is the #halt causing your problem? I ask because if you are using a WAGemStoneProductionErrorHandler for Seaside then all halts, breakpoints and errors should be caught, added to the objectLog and an error message presented to the user ... the WAGemStoneProductionErrorHandler doesn't prevent a gem from going down due to out-of-memory or a handfull of other issues, but the run of the mill errors and halts should be caught .... > > I do recommend that you arrange to have gems automatically restarted when they die and for ss3 I use daemontools[1] ... it's a bit of a pain to set up, but works well once you get it going ... > > I assume that their are other solutions out there and I'm curious what other folks might use. > > Dale > > [1] http://code.google.com/p/glassdb/wiki/GLASSDaemonTools > > ----- Original Message ----- > | From: "Dario Trussardi" <[hidden email]> > | To: "beta discussion Gemstone Seaside" <[hidden email]> > | Sent: Thursday, March 14, 2013 3:21:48 AM > | Subject: [GS/SS Beta] Gem go down for WAFileLibrary error > | > | Ciao, > | > | i work with Gemstone 3.1.0.2 but i remember the same problem in hold > | version. > | > | > | When the system answer a request relative to a WAFileLibrary subclass > | > | and one specific method for example: > | > | > styleBaseCss > | > > | > self halt. > | > > | > ^' > | > /* CSS DTR Personalizzazioni */ > | > /* *** DTR thought, designed and developed by Dario Trussardi Romano *** > | > */ > | > .colorBaseSctLcn{ > | > color: green; > | > } > | > | erase an error the GEM go down. > | > | After three web request the environment is inaccessible ( all based GEM is > | down ) > | > | Thank, > | > | Dario > | > | > | P.S. How i can restart in automatic the gem when it go down ? > | > | There is a script that handles this issue on Ubuntu system? |
Re: Gem go down for WAFileLibrary error
|
|
Are you using WAGemStoneProductionErrorHandler?
Dale ----- Original Message ----- | From: "Dario Trussardi" <[hidden email]> | To: "GemStone Seaside beta discussion" <[hidden email]> | Sent: Thursday, March 14, 2013 9:49:41 AM | Subject: Re: [GS/SS Beta] Gem go down for WAFileLibrary error | | | Ciao Dale, | | the halt is only for understand. | | I can create a styleBaseCss with dynamic code ( it's not elegant ? ) ant it | can go into error. | | Thanks, | | Dario | | > Dario, | > | > First ... is the #halt causing your problem? I ask because if you are using | > a WAGemStoneProductionErrorHandler for Seaside then all halts, breakpoints | > and errors should be caught, added to the objectLog and an error message | > presented to the user ... the WAGemStoneProductionErrorHandler doesn't | > prevent a gem from going down due to out-of-memory or a handfull of other | > issues, but the run of the mill errors and halts should be caught .... | > | > I do recommend that you arrange to have gems automatically restarted when | > they die and for ss3 I use daemontools[1] ... it's a bit of a pain to set | > up, but works well once you get it going ... | > | > I assume that their are other solutions out there and I'm curious what | > other folks might use. | > | > Dale | > | > [1] http://code.google.com/p/glassdb/wiki/GLASSDaemonTools | > | > ----- Original Message ----- | > | From: "Dario Trussardi" <[hidden email]> | > | To: "beta discussion Gemstone Seaside" <[hidden email]> | > | Sent: Thursday, March 14, 2013 3:21:48 AM | > | Subject: [GS/SS Beta] Gem go down for WAFileLibrary error | > | | > | Ciao, | > | | > | i work with Gemstone 3.1.0.2 but i remember the same problem in hold | > | version. | > | | > | | > | When the system answer a request relative to a WAFileLibrary subclass | > | | > | and one specific method for example: | > | | > | > styleBaseCss | > | > | > | > self halt. | > | > | > | > ^' | > | > /* CSS DTR Personalizzazioni */ | > | > /* *** DTR thought, designed and developed by Dario Trussardi Romano | > | > *** | > | > */ | > | > .colorBaseSctLcn{ | > | > color: green; | > | > } | > | | > | erase an error the GEM go down. | > | | > | After three web request the environment is inaccessible ( all based GEM | > | is | > | down ) | > | | > | Thank, | > | | > | Dario | > | | > | | > | P.S. How i can restart in automatic the gem when it go down ? | > | | > | There is a script that handles this issue on Ubuntu system? | |
Restart in automatic the gem when it go down
|
|
In reply to this post by Dale Henrichs
Ciao,
I do recommend that you arrange to have gems automatically restarted when they die and for ss3 I use daemontools[1] ... it's a bit of a pain to set up, but works well once you get it going ... i follow your indications Dale and the : https://github.com/Monty/GemStone_daemontools_setup In dettails i run only the: GemStone_daemontools_setup$ sudo ./daemontools_setup it report : daemontools_setup creates GemStone templates in /etc/sv for daemontools to run
Seaside gems, a maintenance gem, and statmons. It does not create links in /etc/service.
Shall I continue? (Y/N)
Y
error: ls: impossibile accedere a /home/glass: File o directory non esistente
Created daemontools templates:
/etc/sv/gs_maintenance /etc/sv/gs_seaside-9011 /etc/sv/gs_statmon-1 /etc/sv/gstemplate_seaside
/etc/sv/gs_seaside-9010 /etc/sv/gs_seaside-9012 /etc/sv/gs_statmon-60 My Ubuntu server run some glass environment. That where i do test for DaemonTools start with the script: source /DTRDataBase/opt3102/gemstone/product/seaside/defSeaside ## export GEMSTONE_LOGDIR=$GEMSTONE/EnvWorking/data export GEMSTONE_DATADIR=$GEMSTONE/EnvWorking/data ## export GEMSTONE_NAME=working export GEMSTONE_SYS_CONF=$GEMSTONE_DATADIR/system.conf export PATH=$GEMSTONE/EnvWorking/bin:$PATH ## $GEMSTONE/EnvWorking/bin/startGemstone ##$GEMSTONE/EnvWorking/bin/runSeasideGems30 start WAFastCGIAdaptor "9010 9011 9012" $GEMSTONE/EnvWorking/bin/startnet I update the /etc/service/gs_seaside-9010/run file #!/bin/bash ## ##source /etc/default/gemstone ( i erase it because i don't find the relative directory. Link with the ./daemontools_setup error ? ) ## source /DTRDataBase/opt3102/gemstone/product/seaside/defSeaside ## source $GEMSTONE_CONFIG scriptpath=$(dirname $0) [ -r $scriptpath/config.local ] && source $scriptpath/config.local $GEMSTONE/bin/waitstone working 2 exec setuidgid glass $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT A) Now when i start the relative daemontool service and the working stone is down the loop work for 2 minutes and after loop again. B) After start the working stone the relative pid report by sudo svstat * change any seconds gs_seaside-9010: up (pid 25158) 1 seconds C) i call directly the run script into a shell it report: dario@monviso:/etc/sv/gs_seaside-9010$ ./run
./run: riga 7: source: necessario un nome file come argomento
source: uso: source nomefile [argomenti]
_____________________________________________________________________________
| GemStone/S64 Object-Oriented Data Management System |
| Copyright (C) VMware, Inc. 1986-2012 |
| All rights reserved. |
+-----------------------------------------------------------------------------+
| PROGRAM: WAITSTONE, GemStone Remote Process Utility |
| VERSION: 3.1.0.2, Beta Wed Nov 28 16:23:21 2012 |
| BUILD: gss64_3_1_0_x_branch-29651 |
| BUILT FOR: x86-64 (Linux) |
| MODE: 64 bit |
| RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue |
| Feb 19 12:18:21 UTC 2013) 2002MB |
| PROCESS ID: 25762 DATE: 19/03/2013 15:35:05 CET |
| USER IDS: REAL=dario (1000) EFFECTIVE=dario (1000) |
| DATEFORMAT: %d/%m/%Y %H:%M:%S %Z |
_____________________________________________________________________________
| GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone |
|_____________________________________________________________________________|
Network service !#server!working is ready.
setuidgid: fatal: unknown account glass i do test changing the run file with: exec setuidgid dario $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT it report : Network service !#server!working is ready.
setuidgid: fatal: unable to setgid: permission denied I need to create a new user? I wrong the run setup? Any idea? Thanks, Dario |
Re: Restart in automatic the gem when it go down
|
|
Dario,
I'm afraid that I'm not a daemontools expert ... Monty (who has since retired) set up the daemontools on the ss3 server, so I'm not familiar with the fiddling that he had to do to get it running ... I can say that once it is up and running it does the job. I seem to recall that daemontools is sensitive to which version of linux it is run against and that may be the source of the issues you are hitting... I'll try to answer your questions below, but I'm warning you that I'm not that familiar with the ins and outs of installing daemontools... ----- Original Message ----- | From: "Dario Trussardi" <[hidden email]> | To: "GemStone Seaside beta discussion" <[hidden email]> | Sent: Tuesday, March 19, 2013 7:47:56 AM | Subject: [GS/SS Beta] Restart in automatic the gem when it go down | | Ciao, | | | > I do recommend that you arrange to have gems automatically restarted when | > they die and for ss3 I use daemontools[1] ... it's a bit of a pain to set | > up, but works well once you get it going ... | > | > I assume that their are other solutions out there and I'm curious what | > other folks might use. | > | > Dale | > | > [1] http://code.google.com/p/glassdb/wiki/GLASSDaemonTools | | | i follow your indications Dale and the : | https://github.com/Monty/GemStone_daemontools_setup | | | In dettails i run only the: GemStone_daemontools_setup$ sudo | ./daemontools_setup | | it report : | | daemontools_setup creates GemStone templates in /etc/sv for daemontools | to run | Seaside gems, a maintenance gem, and statmons. It does not create links | in /etc/service. | Shall I continue? (Y/N) | Y | | error: ls: impossibile accedere a /home/glass: File o directory non | esistente | Created daemontools templates: | /etc/sv/gs_maintenance /etc/sv/gs_seaside-9011 /etc/sv/gs_statmon-1 | /etc/sv/gstemplate_seaside | /etc/sv/gs_seaside-9010 /etc/sv/gs_seaside-9012 /etc/sv/gs_statmon-60 It looks to me like the setup script was written expecting /home/glass to exist ... looking at the script itself[1], `/home` is being used in the creation of the statmonitor services ... without a `/home/glass` directory (and associated subdirectories), those services will be constantly failing .... [1] https://github.com/Monty/GemStone_daemontools_setup/blob/master/daemontools_setup#L83 | | | My Ubuntu server run some glass environment. | | That where i do test for DaemonTools start with the script: | | source /DTRDataBase/opt3102/gemstone/product/seaside/defSeaside | ## | export GEMSTONE_LOGDIR=$GEMSTONE/EnvWorking/data | export GEMSTONE_DATADIR=$GEMSTONE/EnvWorking/data | ## | export GEMSTONE_NAME=working | export GEMSTONE_SYS_CONF=$GEMSTONE_DATADIR/system.conf | export PATH=$GEMSTONE/EnvWorking/bin:$PATH | ## | $GEMSTONE/EnvWorking/bin/startGemstone | ##$GEMSTONE/EnvWorking/bin/runSeasideGems30 start WAFastCGIAdaptor "9010 | 9011 9012" | $GEMSTONE/EnvWorking/bin/startnet | | | I update the /etc/service/gs_seaside-9010/run file | | #!/bin/bash | ## | ##source /etc/default/gemstone ( i erase it because i don't find the | relative directory. Link with the ./daemontools_setup error ? ) | ## | source /DTRDataBase/opt3102/gemstone/product/seaside/defSeaside | ## | source $GEMSTONE_CONFIG | scriptpath=$(dirname $0) | [ -r $scriptpath/config.local ] && source $scriptpath/config.local | $GEMSTONE/bin/waitstone working 2 | exec setuidgid glass $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT Here's the contents of the /etc/default/gemstone file from ss3: #!/bin/bash # Enable Gemstone init scripts, necessary for start on boot # 1=enabled 0=disabled ENABLED=1 # Defaults used by daemontools setups and execution scripts # Modify this file if needed before running setup scripts # Needed for daemontools export TEMPLATE_DIR="/etc/sv" # Holds template directories containing daemontools scripts. export SERVICE_DIR="/etc/service" # Holds directories that get linked to template directories. # Needed by setup scripts export SEASIDE_VERSION=3.0 # Must be 2.8 or 3.0 export STARTING_PORT=9001 # First port for Gems -- will increment by one through ending port export ENDING_PORT=9003 # Last port for Gems export WWW_DOCROOT="/var/www" # Static document-root for lighttpd config # The following file must export these ENV variables: # GEMSTONE, GEMSTONE_LOGDIR, GEMSTONE_NAME, GEMSTONE_USER export GEMSTONE_CONFIG="/opt/gemstone/product/seaside/defSeaside" # GemStone ENV setup file I'm suspicious of the variable values in the `Needed by setup scripts` section, but the other things are likely to be needed? | | A) Now when i start the relative daemontool service and the working stone is | down the loop work for 2 minutes and after loop again. To start the system you should only have to do: <path to git checkout>/GemStone_daemontools_setup/bin/gemstone_start That script starts: netldi, stone, statmon, and seaside gems ... I always start/stop using the scripts in <path to git checkout>/GemStone_daemontools_setup/bin/*. If you are not using those scripts, you should at least look at them to see how the whole system is intended to work ... It's likely that the problems below are occuring because you haven't run some of the other expected scripts? | | B) After start the working stone the relative pid report by sudo svstat * | | change any seconds | | gs_seaside-9010: up (pid 25158) 1 seconds | | | C) i call directly the run script into a shell it report: | | dario@monviso:/etc/sv/gs_seaside-9010$ ./run | | ./run: riga 7: source: necessario un nome file come argomento | source: uso: source nomefile [argomenti] | | _____________________________________________________________________________ | | GemStone/S64 Object-Oriented Data Management System | | | | | Copyright (C) VMware, Inc. 1986-2012 | | | | | All rights reserved. | | | | +-----------------------------------------------------------------------------+ | | PROGRAM: WAITSTONE, GemStone Remote Process Utility | | | | | VERSION: 3.1.0.2, Beta Wed Nov 28 16:23:21 2012 | | | | | BUILD: gss64_3_1_0_x_branch-29651 | | | | | BUILT FOR: x86-64 (Linux) | | | | | MODE: 64 bit | | | | | RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue | | | | | Feb 19 12:18:21 UTC 2013) 2002MB | | | | | PROCESS ID: 25762 DATE: 19/03/2013 15:35:05 CET | | | | | USER IDS: REAL=dario (1000) EFFECTIVE=dario (1000) | | | | | DATEFORMAT: %d/%m/%Y %H:%M:%S %Z | | | | _____________________________________________________________________________ | | GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone | | | | |_____________________________________________________________________________| | Network service !#server!working is ready. | setuidgid: fatal: unknown account glass | | | i do test changing the run file with: | | exec setuidgid dario $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT | | it report : | | Network service !#server!working is ready. | setuidgid: fatal: unable to setgid: permission denied | | I need to create a new user? | | I wrong the run setup? | | Any idea? | | Thanks, | | Dario | | | |
Re: Restart in automatic the gem when it go down
|
|
Dear Dario and Dale
Am 19.03.2013 um 18:25 schrieb Dale Henrichs <[hidden email]>: > Dario, > > I'm afraid that I'm not a daemontools expert ... Monty (who has since retired) set up the daemontools on the ss3 server, so I'm not familiar with the fiddling that he had to do to get it running ... I can say that once it is up and running it does the job. > > I seem to recall that daemontools is sensitive to which version of linux it is run against and that may be the source of the issues you are hitting... > > I'll try to answer your questions below, but I'm warning you that I'm not that familiar with the ins and outs of installing daemontools... As I wrote the initial tutorial on how to setup gems with daemontools[1], feel free to contact or ask me, i am surely willing to help :) best -Tobias [1] https://code.google.com/p/glassdb/wiki/GLASSDaemonTools |
Re: Restart in automatic the gem when it go down
|
|
Ciao Tobias, Thanks for your collaboration.
My server system is based o Ubuntu and run some stone ( 2.4 and 3.1.0.2 version ) I'm interested to setup the 3.1.0.2 and soon GemStone/S 3.1.0.3 For setup the Daemon gemstone configuration i use the In dettails i run only the: GemStone_daemontools_setup$ sudo ./daemontools_setup it report : daemontools_setup creates GemStone templates in /etc/sv for daemontools to run
Seaside gems, a maintenance gem, and statmons. It does not create links in /etc/service.
Shall I continue? (Y/N)
Y
error: ls: impossibile accedere a /home/glass: File o directory non esistente
Created daemontools templates:
/etc/sv/gs_maintenance /etc/sv/gs_seaside-9011 /etc/sv/gs_statmon-1 /etc/sv/gstemplate_seaside
/etc/sv/gs_seaside-9010 /etc/sv/gs_seaside-9012 /etc/sv/gs_statmon-60 It's create a /etc/sv/gstemplate_seaside directory with run file set to: #!/bin/bash
source /etc/default/gemstone
source $GEMSTONE_CONFIG
scriptpath=$(dirname $0)
[ -r $scriptpath/config.local ] && source $scriptpath/config.local
$GEMSTONE/bin/waitstone working 2
exec setuidgid dario $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT Where i setup $GEMSTONE/bin/waitstone to "working" It is the stoneName ( 3.1.0.2 version ) I start the stone with the script: source /DTRDataBase/opt3102/gemstone/product/seaside/defSeaside ## export GEMSTONE_LOGDIR=$GEMSTONE/EnvWorking/data export GEMSTONE_DATADIR=$GEMSTONE/EnvWorking/data ## export GEMSTONE_NAME=working export GEMSTONE_SYS_CONF=$GEMSTONE_DATADIR/system.conf export PATH=$GEMSTONE/EnvWorking/bin:$PATH ## $GEMSTONE/EnvWorking/bin/startGemstone ##$GEMSTONE/EnvWorking/bin/runSeasideGems30 start WAFastCGIAdaptor "9010 9011 9012" $GEMSTONE/EnvWorking/bin/startnet I setup the /etc/default/gemstone to: #!/bin/bash
# Enable Gemstone init scripts, necessary for start on boot
# 1=enabled 0=disabled
ENABLED=1
# Defaults used by daemontools setups and execution scripts
# Modify this file if needed before running setup scripts
# Needed for daemontools
export TEMPLATE_DIR="/etc/sv" # Holds template directories containing daemontools scripts.
export SERVICE_DIR="/etc/service" # Holds directories that get linked to template directories.
# Needed by setup scripts
export SEASIDE_VERSION=3.0 # Must be 2.8 or 3.0
export STARTING_PORT=9010 # First port for Gems -- will increment by one through ending port
export ENDING_PORT=9012 # Last port for Gems
export WWW_DOCROOT="/var/www" # Static document-root for lighttpd config
# The following file must export these ENV variables:
# GEMSTONE, GEMSTONE_LOGDIR, GEMSTONE_NAME, GEMSTONE_USER
export GEMSTONE_CONFIG="/DTRDataBase/opt3102/gemstone/product/seaside/defSeaside" # GemStone ENV setup file A) Now when i start the relative daemontool service and the "working" stone is down the relative pid work for 2 minutes and after create a new process. ( this means the daemontools work well ) B) After start the " working " stone the relative pid report by sudo svstat * change any seconds gs_seaside-9010: up (pid 25158) 1 seconds It don't know if it's correct but to test the run script i call it directly with the command: dario@monviso:/etc/sv/gs_seaside-9010$ sudo ./run _____________________________________________________________________________ | GemStone/S64 Object-Oriented Data Management System | | Copyright (C) VMware, Inc. 1986-2012 | | All rights reserved. | +-----------------------------------------------------------------------------+ | PROGRAM: WAITSTONE, GemStone Remote Process Utility | | VERSION: 3.1.0.2, Beta Wed Nov 28 16:23:21 2012 | | BUILD: gss64_3_1_0_x_branch-29651 | | BUILT FOR: x86-64 (Linux) | | MODE: 64 bit | | RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue | | Feb 19 12:18:21 UTC 2013) 2002MB | | PROCESS ID: 32108 DATE: 20/03/2013 11:14:02 CET | | USER IDS: REAL=root (0) EFFECTIVE=root (0) | | DATEFORMAT: %d/%m/%Y %H:%M:%S %Z | _____________________________________________________________________________ | GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone | |_____________________________________________________________________________| Network service !#server!working is ready. setuidgid: fatal: unable to run /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30: file does not exist THE seasideGem30 doesn't exist. I wrong something ? What do you suggest? Do the Monty setupAll.sh (without lighttpd_setup) Thank for any consideration. Dario |
Re: Restart in automatic the gem when it go down
|
|
Ciao, i add some notes:
Ok, i found it into Monty git repository, and copy it to: /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 Now when do: sudo ./run the system don't erase any error but the gem don't start. The daemontools behaves as before: the relative pid report by sudo svstat * change any seconds gs_seaside-9010: up (pid 25158) 1 seconds
Thank for any consideration. Dario |
Re: Restart in automatic the gem when it go down
|
|
Am 20.03.2013 um 15:14 schrieb Dario Trussardi <[hidden email]>:
> Ciao, > > i add some notes: > >> Ciao Tobias, >> >> Thanks for your collaboration. >> >>> >>> As I wrote the initial tutorial on how to >>> setup gems with daemontools[1], feel free >>> to contact or ask me, i am surely willing to >>> help :) >>> >>> best >>> -Tobias >>> >>> >>> >>> >>> [1] https://code.google.com/p/glassdb/wiki/GLASSDaemonTools >> >> My server system is based o Ubuntu and run some stone ( 2.4 and 3.1.0.2 version ) >> >> I'm interested to setup the 3.1.0.2 and soon GemStone/S 3.1.0.3 >> >> >> For setup the Daemon gemstone configuration i use the >> >> https://github.com/Monty/GemStone_daemontools_setup >> >> >> In dettails i run only the: GemStone_daemontools_setup$ sudo ./daemontools_setup >> >> it report : >> >> daemontools_setup creates GemStone templates in /etc/sv for daemontools to run >> Seaside gems, a maintenance gem, and statmons. It does not create links in /etc/service. >> Shall I continue? (Y/N) >> Y >> >> >> error: ls: impossibile accedere a /home/glass: File o directory non esistente >> >> Created daemontools templates: >> /etc/sv/gs_maintenance /etc/sv/gs_seaside-9011 /etc/sv/gs_statmon-1 /etc/sv/gstemplate_seaside >> /etc/sv/gs_seaside-9010 /etc/sv/gs_seaside-9012 /etc/sv/gs_statmon-60 >> >> >> >> It's create a /etc/sv/gstemplate_seaside directory with run file set to: >> >> #!/bin/bash >> source /etc/default/gemstone >> source $GEMSTONE_CONFIG >> scriptpath=$(dirname $0) >> [ -r $scriptpath/config.local ] && source $scriptpath/config.local >> $GEMSTONE/bin/waitstone working 2 >> exec setuidgid dario $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT >> >> >> >> Where i setup $GEMSTONE/bin/waitstone to "working" It is the stoneName ( 3.1.0.2 version ) >> >> I start the stone with the script: >> >> source /DTRDataBase/opt3102/gemstone/product/seaside/defSeaside >> ## >> export GEMSTONE_LOGDIR=$GEMSTONE/EnvWorking/data >> export GEMSTONE_DATADIR=$GEMSTONE/EnvWorking/data >> ## >> export GEMSTONE_NAME=working >> export GEMSTONE_SYS_CONF=$GEMSTONE_DATADIR/system.conf >> export PATH=$GEMSTONE/EnvWorking/bin:$PATH >> ## >> $GEMSTONE/EnvWorking/bin/startGemstone >> ##$GEMSTONE/EnvWorking/bin/runSeasideGems30 start WAFastCGIAdaptor "9010 9011 9012" >> $GEMSTONE/EnvWorking/bin/startnet >> >> >> >> I setup the /etc/default/gemstone to: >> >> #!/bin/bash >> # Enable Gemstone init scripts, necessary for start on boot >> # 1=enabled 0=disabled >> ENABLED=1 >> >> # Defaults used by daemontools setups and execution scripts >> # Modify this file if needed before running setup scripts >> >> # Needed for daemontools >> export TEMPLATE_DIR="/etc/sv" # Holds template directories containing daemontools scripts. >> export SERVICE_DIR="/etc/service" # Holds directories that get linked to template directories. >> >> # Needed by setup scripts >> export SEASIDE_VERSION=3.0 # Must be 2.8 or 3.0 >> export STARTING_PORT=9010 # First port for Gems -- will increment by one through ending port >> export ENDING_PORT=9012 # Last port for Gems >> export WWW_DOCROOT="/var/www" # Static document-root for lighttpd config >> >> # The following file must export these ENV variables: >> # GEMSTONE, GEMSTONE_LOGDIR, GEMSTONE_NAME, GEMSTONE_USER >> export GEMSTONE_CONFIG="/DTRDataBase/opt3102/gemstone/product/seaside/defSeaside" # GemStone ENV setup file >> >> >> >> >> A) Now when i start the relative daemontool service and the "working" stone is down the relative pid work for 2 minutes >> and after create a new process. >> ( this means the daemontools work well ) >> >> B) After start the " working " stone the relative pid report by sudo svstat * >> >> change any seconds >> >> gs_seaside-9010: up (pid 25158) 1 seconds >> >> >> >> It don't know if it's correct but to test the run script i call it directly with the command: >> >> >> dario@monviso:/etc/sv/gs_seaside-9010$ sudo ./run >> _____________________________________________________________________________ >> | GemStone/S64 Object-Oriented Data Management System | >> | Copyright (C) VMware, Inc. 1986-2012 | >> | All rights reserved. | >> +-----------------------------------------------------------------------------+ >> | PROGRAM: WAITSTONE, GemStone Remote Process Utility | >> | VERSION: 3.1.0.2, Beta Wed Nov 28 16:23:21 2012 | >> | BUILD: gss64_3_1_0_x_branch-29651 | >> | BUILT FOR: x86-64 (Linux) | >> | MODE: 64 bit | >> | RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue | >> | Feb 19 12:18:21 UTC 2013) 2002MB | >> | PROCESS ID: 32108 DATE: 20/03/2013 11:14:02 CET | >> | USER IDS: REAL=root (0) EFFECTIVE=root (0) | >> | DATEFORMAT: %d/%m/%Y %H:%M:%S %Z | >> _____________________________________________________________________________ >> | GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone | >> |_____________________________________________________________________________| >> Network service !#server!working is ready. >> setuidgid: fatal: unable to run /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30: file does not exist >> > > Ok, i found it into Monty git repository, and copy it to: /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 > > Now when do: sudo ./run the system don't erase any error but the gem don't start. > > > The daemontools behaves as before: > > the relative pid report by sudo svstat * > > change any seconds > > gs_seaside-9010: up (pid 25158) 1 seconds do you have mlcat installed? if so try 'mlcat gs_seaside-9010' and see what the error is. if not look at gs_seaside-9010/log/main/current where the latest log entries should be. “run” should be a shell script. can you look at what happens when you do not call “run” but “bash -x run”? Best -Tobias |
Re: Restart in automatic the gem when it go down
|
|
> Am 20.03.2013 um 15:14 schrieb Dario Trussardi <[hidden email]>: > >> Ciao, >> >> i add some notes: >> >>> Ciao Tobias, >>> >>> Thanks for your collaboration. >>> >>>> >>>> As I wrote the initial tutorial on how to >>>> setup gems with daemontools[1], feel free >>>> to contact or ask me, i am surely willing to >>>> help :) >>>> >>>> best >>>> -Tobias >>>> >>>> >>>> >>>> >>>> [1] https://code.google.com/p/glassdb/wiki/GLASSDaemonTools >>> >>> My server system is based o Ubuntu and run some stone ( 2.4 and 3.1.0.2 version ) >>> >>> I'm interested to setup the 3.1.0.2 and soon GemStone/S 3.1.0.3 >>> >>> >>> For setup the Daemon gemstone configuration i use the >>> >>> https://github.com/Monty/GemStone_daemontools_setup >>> >>> >>> In dettails i run only the: GemStone_daemontools_setup$ sudo ./daemontools_setup >>> >>> it report : >>> >>> daemontools_setup creates GemStone templates in /etc/sv for daemontools to run >>> Seaside gems, a maintenance gem, and statmons. It does not create links in /etc/service. >>> Shall I continue? (Y/N) >>> Y >>> >>> >>> error: ls: impossibile accedere a /home/glass: File o directory non esistente >>> >>> Created daemontools templates: >>> /etc/sv/gs_maintenance /etc/sv/gs_seaside-9011 /etc/sv/gs_statmon-1 /etc/sv/gstemplate_seaside >>> /etc/sv/gs_seaside-9010 /etc/sv/gs_seaside-9012 /etc/sv/gs_statmon-60 >>> >>> >>> >>> It's create a /etc/sv/gstemplate_seaside directory with run file set to: >>> >>> #!/bin/bash >>> source /etc/default/gemstone >>> source $GEMSTONE_CONFIG >>> scriptpath=$(dirname $0) >>> [ -r $scriptpath/config.local ] && source $scriptpath/config.local >>> $GEMSTONE/bin/waitstone working 2 >>> exec setuidgid dario $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT >>> >>> >>> >>> Where i setup $GEMSTONE/bin/waitstone to "working" It is the stoneName ( 3.1.0.2 version ) >>> >>> I start the stone with the script: >>> >>> source /DTRDataBase/opt3102/gemstone/product/seaside/defSeaside >>> ## >>> export GEMSTONE_LOGDIR=$GEMSTONE/EnvWorking/data >>> export GEMSTONE_DATADIR=$GEMSTONE/EnvWorking/data >>> ## >>> export GEMSTONE_NAME=working >>> export GEMSTONE_SYS_CONF=$GEMSTONE_DATADIR/system.conf >>> export PATH=$GEMSTONE/EnvWorking/bin:$PATH >>> ## >>> $GEMSTONE/EnvWorking/bin/startGemstone >>> ##$GEMSTONE/EnvWorking/bin/runSeasideGems30 start WAFastCGIAdaptor "9010 9011 9012" >>> $GEMSTONE/EnvWorking/bin/startnet >>> >>> >>> >>> I setup the /etc/default/gemstone to: >>> >>> #!/bin/bash >>> # Enable Gemstone init scripts, necessary for start on boot >>> # 1=enabled 0=disabled >>> ENABLED=1 >>> >>> # Defaults used by daemontools setups and execution scripts >>> # Modify this file if needed before running setup scripts >>> >>> # Needed for daemontools >>> export TEMPLATE_DIR="/etc/sv" # Holds template directories containing daemontools scripts. >>> export SERVICE_DIR="/etc/service" # Holds directories that get linked to template directories. >>> >>> # Needed by setup scripts >>> export SEASIDE_VERSION=3.0 # Must be 2.8 or 3.0 >>> export STARTING_PORT=9010 # First port for Gems -- will increment by one through ending port >>> export ENDING_PORT=9012 # Last port for Gems >>> export WWW_DOCROOT="/var/www" # Static document-root for lighttpd config >>> >>> # The following file must export these ENV variables: >>> # GEMSTONE, GEMSTONE_LOGDIR, GEMSTONE_NAME, GEMSTONE_USER >>> export GEMSTONE_CONFIG="/DTRDataBase/opt3102/gemstone/product/seaside/defSeaside" # GemStone ENV setup file >>> >>> >>> >>> >>> A) Now when i start the relative daemontool service and the "working" stone is down the relative pid work for 2 minutes >>> and after create a new process. >>> ( this means the daemontools work well ) >>> >>> B) After start the " working " stone the relative pid report by sudo svstat * >>> >>> change any seconds >>> >>> gs_seaside-9010: up (pid 25158) 1 seconds >>> >>> >>> >>> It don't know if it's correct but to test the run script i call it directly with the command: >>> >>> >>> dario@monviso:/etc/sv/gs_seaside-9010$ sudo ./run >>> _____________________________________________________________________________ >>> | GemStone/S64 Object-Oriented Data Management System | >>> | Copyright (C) VMware, Inc. 1986-2012 | >>> | All rights reserved. | >>> +-----------------------------------------------------------------------------+ >>> | PROGRAM: WAITSTONE, GemStone Remote Process Utility | >>> | VERSION: 3.1.0.2, Beta Wed Nov 28 16:23:21 2012 | >>> | BUILD: gss64_3_1_0_x_branch-29651 | >>> | BUILT FOR: x86-64 (Linux) | >>> | MODE: 64 bit | >>> | RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue | >>> | Feb 19 12:18:21 UTC 2013) 2002MB | >>> | PROCESS ID: 32108 DATE: 20/03/2013 11:14:02 CET | >>> | USER IDS: REAL=root (0) EFFECTIVE=root (0) | >>> | DATEFORMAT: %d/%m/%Y %H:%M:%S %Z | >>> _____________________________________________________________________________ >>> | GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone | >>> |_____________________________________________________________________________| >>> Network service !#server!working is ready. >>> setuidgid: fatal: unable to run /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30: file does not exist >>> >> >> Ok, i found it into Monty git repository, and copy it to: /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 >> >> Now when do: sudo ./run the system don't erase any error but the gem don't start. >> >> >> The daemontools behaves as before: >> >> the relative pid report by sudo svstat * >> >> change any seconds >> >> gs_seaside-9010: up (pid 25158) 1 seconds > > do you have mlcat installed? > if so > try 'mlcat gs_seaside-9010' and see what the error is. mlcat -V mlcat 0.6 But: /etc$ sudo mlcat gs_seaside-9010 svok: fatal: unable to chdir to /etc/service/gs_seaside-9010/log: file does not exist > if not > look at gs_seaside-9010/log/main/current > where the latest log entries should be. don't find the /log > “run” should be a shell script. > can you look at what happens when you do not call “run” but “bash -x run” bash -x run + source /etc/default/gemstone ++ ENABLED=1 ++ export TEMPLATE_DIR=/etc/sv ++ TEMPLATE_DIR=/etc/sv ++ export SERVICE_DIR=/etc/service ++ SERVICE_DIR=/etc/service ++ export SEASIDE_VERSION=3.0 ++ SEASIDE_VERSION=3.0 ++ export STARTING_PORT=9010 ++ STARTING_PORT=9010 ++ export ENDING_PORT=9012 ++ ENDING_PORT=9012 ++ export WWW_DOCROOT=/var/www ++ WWW_DOCROOT=/var/www ++ export GEMSTONE_CONFIG=/DTRDataBase/opt3102/gemstone/product/seaside/defSeaside ++ GEMSTONE_CONFIG=/DTRDataBase/opt3102/gemstone/product/seaside/defSeaside + source /DTRDataBase/opt3102/gemstone/product/seaside/defSeaside ++ '[' -r /DTRDataBase/opt3102/gemstone/product/seaside/etc/gemstone.conf ']' ++ . /DTRDataBase/opt3102/gemstone/product/seaside/etc/gemstone.conf +++ GEMSTONE_USER=glass +++ GEMSTONE_NAME=seaside +++ GEMSTONE=/DTRDataBase/opt3102/gemstone/product +++ GEMSTONE_LOGDIR=/DTRDataBase/opt3102/gemstone/log +++ GEMSTONE_KEYFILE=/DTRDataBase/opt3102/gemstone/product/seaside/etc/gemstone.key +++ GEMSTONE_DATADIR=/DTRDataBase/opt3102/gemstone/product/seaside/data +++ GEMSTONE_SYS_CONF=/DTRDataBase/opt3102/gemstone/product/seaside/data/system.conf +++ GEMSTONE_EXE_CONF=/DTRDataBase/opt3102/gemstone/product/seaside/data +++ PATH=/DTRDataBase/opt3102/gemstone/product/bin:/DTRDataBase/opt3102/gemstone/product/seaside/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games +++ MANPATH=/DTRDataBase/opt3102/gemstone/product/doc: +++ LD_LIBRARY_PATH=/DTRDataBase/opt3102/gemstone/product/lib: +++ DYLD_LIBRARY_PATH=/DTRDataBase/opt3102/gemstone/product/lib: ++ export GEMSTONE_GLOBAL_DIR=/DTRDataBase/opt3102/gemstone ++ GEMSTONE_GLOBAL_DIR=/DTRDataBase/opt3102/gemstone ++ GS_LEN=37 ++ [[ /DTRDataBase/opt3102/gemstone/product != /DTRDataBase/opt3102/gemstone/product ]] ++ [[ /DTRDataBase/opt3102/gemstone/product != /DTRDataBase/opt3102/gemstone/product ]] ++ [[ /DTRDataBase/opt3102/gemstone/product != /DTRDataBase/opt3102/gemstone/product ]] ++ [[ /DTRDataBase/opt3102/gemstone/product != /DTRDataBase/opt3102/gemstone/product ]] ++ export GEMSTONE GEMSTONE_LOGDIR GEMSTONE_DATADIR GEMSTONE_KEYFILE ++ export GEMSTONE_NAME GEMSTONE_SYS_CONF GEMSTONE_EXE_CONF ++ export PATH MANPATH LD_LIBRARY_PATH DYLD_LIBRARY_PATH ++ dirname run + scriptpath=. + '[' -r ./config.local ']' + source ./config.local ++ export GEM_PORT=9010 ++ GEM_PORT=9010 + /DTRDataBase/opt3102/gemstone/product/bin/waitstone working 2 _____________________________________________________________________________ | GemStone/S64 Object-Oriented Data Management System | | Copyright (C) VMware, Inc. 1986-2012 | | All rights reserved. | +-----------------------------------------------------------------------------+ | PROGRAM: WAITSTONE, GemStone Remote Process Utility | | VERSION: 3.1.0.2, Beta Wed Nov 28 16:23:21 2012 | | BUILD: gss64_3_1_0_x_branch-29651 | | BUILT FOR: x86-64 (Linux) | | MODE: 64 bit | | RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue | | Feb 19 12:18:21 UTC 2013) 2002MB | | PROCESS ID: 5690 DATE: 20/03/2013 15:43:50 CET | | USER IDS: REAL=dario (1000) EFFECTIVE=dario (1000) | | DATEFORMAT: %d/%m/%Y %H:%M:%S %Z | _____________________________________________________________________________ | GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone | |_____________________________________________________________________________| Network service !#server!working is ready. + exec setuidgid dario /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 setuidgid: fatal: unable to setgid: permission denied Thanks, Dario |
Re: Restart in automatic the gem when it go down
|
|
Am 20.03.2013 um 15:50 schrieb Dario Trussardi <[hidden email]>:
> > >> Am 20.03.2013 um 15:14 schrieb Dario Trussardi <[hidden email]>: >> >>> Ciao, >>> >>> i add some notes: >>> >>> >>> Ok, i found it into Monty git repository, and copy it to: /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 >>> >>> Now when do: sudo ./run the system don't erase any error but the gem don't start. >>> >>> >>> The daemontools behaves as before: >>> >>> the relative pid report by sudo svstat * >>> >>> change any seconds >>> >>> gs_seaside-9010: up (pid 25158) 1 seconds >> >> do you have mlcat installed? >> if so >> try 'mlcat gs_seaside-9010' and see what the error is. > > mlcat -V mlcat 0.6 > > But: > /etc$ sudo mlcat gs_seaside-9010 > svok: fatal: unable to chdir to /etc/service/gs_seaside-9010/log: file does not exist > >> if not >> look at gs_seaside-9010/log/main/current >> where the latest log entries should be. > > don't find the /log > GEMSTONE_LOGDIR=/DTRDataBase/opt3102/gemstone/log > > > >> “run” should be a shell script. >> can you look at what happens when you do not call “run” but “bash -x run” > > bash -x run > [snip] > Network service !#server!working is ready. > + exec setuidgid dario /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 > setuidgid: fatal: unable to setgid: permission denied > this is important. what happpens if you execute sudo setuidgid dario /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 Best -tobias |
Re: Restart in automatic the gem when it go down
|
|
> Am 20.03.2013 um 15:50 schrieb Dario Trussardi <[hidden email]>: > >> >> >>> Am 20.03.2013 um 15:14 schrieb Dario Trussardi <[hidden email]>: >>> >>>> Ciao, >>>> >>>> i add some notes: >>>> >>>> >>>> Ok, i found it into Monty git repository, and copy it to: /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 >>>> >>>> Now when do: sudo ./run the system don't erase any error but the gem don't start. >>>> >>>> >>>> The daemontools behaves as before: >>>> >>>> the relative pid report by sudo svstat * >>>> >>>> change any seconds >>>> >>>> gs_seaside-9010: up (pid 25158) 1 seconds >>> >>> do you have mlcat installed? >>> if so >>> try 'mlcat gs_seaside-9010' and see what the error is. >> >> mlcat -V mlcat 0.6 >> >> But: >> /etc$ sudo mlcat gs_seaside-9010 >> svok: fatal: unable to chdir to /etc/service/gs_seaside-9010/log: file does not exist >> >>> if not >>> look at gs_seaside-9010/log/main/current >>> where the latest log entries should be. >> >> don't find the /log >> > ok, then the logs should be in > GEMSTONE_LOGDIR=/DTRDataBase/opt3102/gemstone/log The daemon_server-9010.log report: GemStone: Error Fatal The given Stone Repository monitor cannot be reached: , could not find server 'seaside' on host 'monviso' because: file not found: /DTRDataBase/opt3102/gemstone/locks/seaside..LCK service seaside not found Error Category: 231169 [GemStone] Number: 4065 Arg Count: 1 Context : 20 exception : 20 Arg 1: 20 Login failed due to errors. topaz > exec iferr 1 : where WHERE can't be used prior to logging in. OK, I update the /etc/default/gemstone ( used by run ) to point a specific defSeaside export GEMSTONE_CONFIG="/DTRDataBase/opt3102/gemstone/product/EnvWorking/defSeaside" # GemStone ENV setup file Now it point a defSeaside where i setup the specific GEMSTONE_NAME # If you want to override any of the default environment variable settings # insert commands to do that here ### DTR Gestione indirizzamento per /opt/gemstone/locks export GEMSTONE_GLOBAL_DIR=/DTRDataBase/opt3102/gemstone export GEMSTONE_NAME=working export GEMSTONE_USER=dario And now when started the daemontools service all work well. The gem start and work. >> >> >> >>> “run” should be a shell script. >>> can you look at what happens when you do not call “run” but “bash -x run” >> >> bash -x run >> [snip] > >> Network service !#server!working is ready. >> + exec setuidgid dario /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 >> setuidgid: fatal: unable to setgid: permission denied >> > > > > this is important. > > what happpens if you execute > sudo setuidgid dario /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 sudo setuidgid dario /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 Missing password file $GEMSTONE/seaside/etc/gemstone.secret I have some other question if you can help me: A) The run file at exec line is : exec setuidgid dario $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT I don't understund the ' daemon ' before $GEM_PORT. What does this mean? I can remove it? B) What is use of : gs_statmon-1 and gs_statmon-60 C) You talk about: It's possible to use the daemontools to control the stone itself. I can use it do start some stones at the boot of the system ? The Monty script manage /bin/gemstone_start /bin/gemstone_stop Are they a good point to do it ? Thanks for your help and for any consideration. Dario |
Re: Restart in automatic the gem when it go down
|
|
Tobias ... thanks for your help.
Dario, embedded comments... ----- Original Message ----- | From: "Dario Trussardi" <[hidden email]> | To: "GemStone Seaside beta discussion" <[hidden email]> | Sent: Wednesday, March 20, 2013 9:24:28 AM | Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down | | | | > Am 20.03.2013 um 15:50 schrieb Dario Trussardi | > <[hidden email]>: | > | >> | >> | >>> Am 20.03.2013 um 15:14 schrieb Dario Trussardi | >>> <[hidden email]>: | >>> | >>>> Ciao, | >>>> | >>>> i add some notes: | >>>> | >>>> | >>>> Ok, i found it into Monty git repository, and copy it to: | >>>> /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 | >>>> | >>>> Now when do: sudo ./run the system don't erase any error but the | >>>> gem don't start. | >>>> | >>>> | >>>> The daemontools behaves as before: | >>>> | >>>> the relative pid report by sudo svstat * | >>>> | >>>> change any seconds | >>>> | >>>> gs_seaside-9010: up (pid 25158) 1 seconds | >>> | >>> do you have mlcat installed? | >>> if so | >>> try 'mlcat gs_seaside-9010' and see what the error is. | >> | >> mlcat -V mlcat 0.6 | >> | >> But: | >> /etc$ sudo mlcat gs_seaside-9010 | >> svok: fatal: unable to chdir to /etc/service/gs_seaside-9010/log: file | >> does not exist | >> | >>> if not | >>> look at gs_seaside-9010/log/main/current | >>> where the latest log entries should be. | >> | >> don't find the /log | >> | > ok, then the logs should be in | > GEMSTONE_LOGDIR=/DTRDataBase/opt3102/gemstone/log | | The daemon_server-9010.log report: | | GemStone: Error Fatal | The given Stone Repository monitor cannot be reached: | , could not find server 'seaside' on host 'monviso' because: | file not found: /DTRDataBase/opt3102/gemstone/locks/seaside..LCK | service seaside not found | Error Category: 231169 [GemStone] Number: 4065 Arg Count: 1 Context : 20 | exception : 20 | Arg 1: 20 | | Login failed due to errors. | topaz > exec iferr 1 : where | WHERE can't be used prior to logging in. | | | | | OK, I update the /etc/default/gemstone ( used by run ) to point a specific | defSeaside | | export | GEMSTONE_CONFIG="/DTRDataBase/opt3102/gemstone/product/EnvWorking/defSeaside" | # GemStone ENV setup file | | Now it point a defSeaside where i setup the specific GEMSTONE_NAME | | # If you want to override any of the default environment variable settings | # insert commands to do that here | | ### DTR Gestione indirizzamento per /opt/gemstone/locks | export GEMSTONE_GLOBAL_DIR=/DTRDataBase/opt3102/gemstone | export GEMSTONE_NAME=working | export GEMSTONE_USER=dario | | And now when started the daemontools service all work well. | | The gem start and work. | | | >> | >> | >> | >>> “run” should be a shell script. | >>> can you look at what happens when you do not call “run” but “bash -x run” | >> | >> bash -x run | >> [snip] | > | >> Network service !#server!working is ready. | >> + exec setuidgid dario | >> /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 | >> setuidgid: fatal: unable to setgid: permission denied | >> | > | > | > | > this is important. | > | > what happpens if you execute | > sudo setuidgid dario | > /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 | | sudo setuidgid dario | /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 | Missing password file $GEMSTONE/seaside/etc/gemstone.secret | | | I have some other question if you can help me: | | A) The run file at exec line is : | | exec setuidgid dario $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT | | I don't understund the ' daemon ' before $GEM_PORT. | | What does this mean? | | I can remove it? The first arg to the script is a name or label used in dumping information to the gem log. The second arg is the listening port. If you remove the `daemon` then you need to modify the script....It looks like seasideGem30 should be based upon $GEMSTONE/seaside/bin/startSeaside30_Adaptor ... | | B) What is use of : | gs_statmon-1 and gs_statmon-60 | | | C) You talk about: It's possible to use the daemontools to control the | stone itself. | | I can use it do start some stones at the boot of the system ? | | The Monty script manage /bin/gemstone_start /bin/gemstone_stop | | Are they a good point to do it ? I'm not exactly sure of the details here, but we've certainly arranged for the ss3 server to start gemstone and the seaside servers on boot ... | | Thanks for your help and for any consideration. | | Dario | | | |
|
|
Hi,
If you're interested, you can try https://github.com/ottobehrens/gemstone-scripts. Okay, this is ruby and not Smalltalk. In glass_stone.rb, there is create_daemontools_structure, which helps to set it up. Also, there's some code that monitors if a process is (really) up. The class is called HyperService, but starts a Swazoo server (file glass_hyper). Could be something like SeasideService. Have been using and tweaking this for a long time on 2.4.4.4. HTH www.FinWorks.biz +27 82 809 2375 On Wed, Mar 20, 2013 at 6:48 PM, Dale Henrichs <[hidden email]> wrote: > Tobias ... thanks for your help. > > Dario, embedded comments... > > ----- Original Message ----- > | From: "Dario Trussardi" <[hidden email]> > | To: "GemStone Seaside beta discussion" <[hidden email]> > | Sent: Wednesday, March 20, 2013 9:24:28 AM > | Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down > | > | > | > | > Am 20.03.2013 um 15:50 schrieb Dario Trussardi > | > <[hidden email]>: > | > > | >> > | >> > | >>> Am 20.03.2013 um 15:14 schrieb Dario Trussardi > | >>> <[hidden email]>: > | >>> > | >>>> Ciao, > | >>>> > | >>>> i add some notes: > | >>>> > | >>>> > | >>>> Ok, i found it into Monty git repository, and copy it to: > | >>>> /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 > | >>>> > | >>>> Now when do: sudo ./run the system don't erase any error but the > | >>>> gem don't start. > | >>>> > | >>>> > | >>>> The daemontools behaves as before: > | >>>> > | >>>> the relative pid report by sudo svstat * > | >>>> > | >>>> change any seconds > | >>>> > | >>>> gs_seaside-9010: up (pid 25158) 1 seconds > | >>> > | >>> do you have mlcat installed? > | >>> if so > | >>> try 'mlcat gs_seaside-9010' and see what the error is. > | >> > | >> mlcat -V mlcat 0.6 > | >> > | >> But: > | >> /etc$ sudo mlcat gs_seaside-9010 > | >> svok: fatal: unable to chdir to /etc/service/gs_seaside-9010/log: file > | >> does not exist > | >> > | >>> if not > | >>> look at gs_seaside-9010/log/main/current > | >>> where the latest log entries should be. > | >> > | >> don't find the /log > | >> > | > ok, then the logs should be in > | > GEMSTONE_LOGDIR=/DTRDataBase/opt3102/gemstone/log > | > | The daemon_server-9010.log report: > | > | GemStone: Error Fatal > | The given Stone Repository monitor cannot be reached: > | , could not find server 'seaside' on host 'monviso' because: > | file not found: /DTRDataBase/opt3102/gemstone/locks/seaside..LCK > | service seaside not found > | Error Category: 231169 [GemStone] Number: 4065 Arg Count: 1 Context : 20 > | exception : 20 > | Arg 1: 20 > | > | Login failed due to errors. > | topaz > exec iferr 1 : where > | WHERE can't be used prior to logging in. > | > | > | > | > | OK, I update the /etc/default/gemstone ( used by run ) to point a specific > | defSeaside > | > | export > | GEMSTONE_CONFIG="/DTRDataBase/opt3102/gemstone/product/EnvWorking/defSeaside" > | # GemStone ENV setup file > | > | Now it point a defSeaside where i setup the specific GEMSTONE_NAME > | > | # If you want to override any of the default environment variable settings > | # insert commands to do that here > | > | ### DTR Gestione indirizzamento per /opt/gemstone/locks > | export GEMSTONE_GLOBAL_DIR=/DTRDataBase/opt3102/gemstone > | export GEMSTONE_NAME=working > | export GEMSTONE_USER=dario > | > | And now when started the daemontools service all work well. > | > | The gem start and work. > | > | > | >> > | >> > | >> > | >>> “run” should be a shell script. > | >>> can you look at what happens when you do not call “run” but “bash -x run” > | >> > | >> bash -x run > | >> [snip] > | > > | >> Network service !#server!working is ready. > | >> + exec setuidgid dario > | >> /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 > | >> setuidgid: fatal: unable to setgid: permission denied > | >> > | > > | > > | > > | > this is important. > | > > | > what happpens if you execute > | > sudo setuidgid dario > | > /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 > | > | sudo setuidgid dario > | /DTRDataBase/opt3102/gemstone/product/seaside/bin/seasideGem30 9010 > | Missing password file $GEMSTONE/seaside/etc/gemstone.secret > | > | > | I have some other question if you can help me: > | > | A) The run file at exec line is : > | > | exec setuidgid dario $GEMSTONE/seaside/bin/seasideGem30 daemon $GEM_PORT > | > | I don't understund the ' daemon ' before $GEM_PORT. > | > | What does this mean? > | > | I can remove it? > > The first arg to the script is a name or label used in dumping information to the gem log. The second arg is the listening port. If you remove the `daemon` then you need to modify the script....It looks like seasideGem30 should be based upon $GEMSTONE/seaside/bin/startSeaside30_Adaptor ... > > | > | B) What is use of : > | gs_statmon-1 and gs_statmon-60 > | > | > | C) You talk about: It's possible to use the daemontools to control the > | stone itself. > | > | I can use it do start some stones at the boot of the system ? > | > | The Monty script manage /bin/gemstone_start /bin/gemstone_stop > | > | Are they a good point to do it ? > > I'm not exactly sure of the details here, but we've certainly arranged for the ss3 server to start gemstone and the seaside servers on boot ... > > | > | Thanks for your help and for any consideration. > | > | Dario > | > | > | |
Re: Restart in automatic the gem when it go down
|
|
In reply to this post by Dale Henrichs
Ciao, Dale
thank to you and Tobias. Today i run the Monty ./setupAll.sh the script go well. The only doubt is relative to > bootGemstone_start links the GemStone/S startup files in /etc/init.d to appropriate > locations in /etc/rc<n>.d for a Ubuntu based GemStone appliance. > You may want to change the destination names for your system. > Shall I continue? (Y/N) > y > ln: creazione del collegamento simbolico "K05topaz" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K07statmon" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K10gemstone" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K20netldi" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K05topaz" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K07statmon" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K10gemstone" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K20netldi" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K05topaz" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K07statmon" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K10gemstone" non riuscita: File già esistente > ln: creazione del collegamento simbolico "K20netldi" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S95gemstone" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S96netldi" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S97statmon" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S98topaz" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S98glass_ip_address" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S95gemstone" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S96netldi" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S97statmon" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S98topaz" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S98glass_ip_address" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S95gemstone" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S96netldi" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S97statmon" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S98topaz" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S98glass_ip_address" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S95gemstone" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S96netldi" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S97statmon" non riuscita: File già esistente > ln: creazione del collegamento simbolico "S98topaz" non riuscita: File già esistente when i redo : sudo bash ./setupAll.sh ( i dont know what is the purpose of this file ) NOW i can manage the bin gemstone_start and the gemstone_stop command GemStone status: Status Version Owner Pid Port Started Type Name ------- --------- --------- ----- ----- ------------ ------ ---- OK 3.1.0.2 dario 16108 45299 mar 21 14:54 Stone working OK 3.1.0.2 dario 11242 50379 mar 21 14:38 Netldi 50379 OK 3.1.0.2 dario 16110 46178 mar 21 14:54 cache working~216579baf3f40c0 I have a problem with the deamtools gs_maintenance it don't start the service. The relative maintenance_gem.log report : _____________________________________________________________________________ | Configuration Files | | | | System File: /mnt/ISTDataBase/DTRdbWorking/data/system.conf | | | | Executable File: /mnt/ISTDataBase//opt3102/gemstone/GemStone64Bit3.1.0.2-x86_64.Linux/seaside/data/gem.conf | Warning: File not found (errno=2,ENOENT, The file or directory specified cannot | be found) | | using defaults. | |_____________________________________________________________________________| Using GEM_TEMPOBJ_CACHE_SIZE 200000 from -T command line option _____________________________________________________________________________ | Gem Configuration Options for process id 1324 | |_____________________________________________________________________________| DUMP_OPTIONS = TRUE; GEM_GCI_LOG_ENABLED = FALSE; GEM_ABORT_MAX_CRS = 0; GEM_FREE_FRAME_CACHE_SIZE = -1; GEM_FREE_FRAME_LIMIT = -1; GEM_FREE_PAGEIDS_CACHE = 200; GEM_HALT_ON_ERROR = 0; GEM_KEEP_MIN_SOFTREFS = 0; GEM_MAX_SMALLTALK_STACK_DEPTH = 1000; GEM_NATIVE_CODE_ENABLED = FALSE; GEM_PRIVATE_PAGE_CACHE_KB = 960; GEM_PGSVR_COMPRESS_PAGE_TRANSFERS = FALSE; GEM_PGSVR_FREE_FRAME_CACHE_SIZE = -1; GEM_PGSVR_FREE_FRAME_LIMIT = -1; GEM_PGSVR_UPDATE_CACHE_ON_READ = FALSE; GEM_RPC_KEEPALIVE_INTERVAL = 0; GEM_RPCGCI_TIMEOUT = 0; GEM_RPC_USE_SSL = TRUE; GEM_SOFTREF_CLEANUP_PERCENT_MEM = 50; GEM_TEMPOBJ_AGGRESSIVE_STUBBING = TRUE; GEM_TEMPOBJ_CACHE_SIZE = 200000; GEM_TEMPOBJ_MESPACE_SIZE = 0; GEM_TEMPOBJ_OOPMAP_SIZE = 0; GEM_TEMPOBJ_SCOPES_SIZE = 2000; GEM_TEMPOBJ_POMGEN_SIZE = 0; GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE = 90; GEM_TEMPOBJ_POMGEN_SCAVENGE_INTERVAL = 1800; CFG_GEM_TEMPOBJ_START_ADDR not used on this platform LOG_WARNINGS = TRUE; SHR_NUM_FREE_FRAME_SERVERS = -1; SHR_PAGE_CACHE_LOCKED = FALSE; SHR_PAGE_CACHE_NUM_PROCS = 4089; SHR_PAGE_CACHE_NUM_SHARED_COUNTERS = 1900; SHR_PAGE_CACHE_PERMISSIONS = 660; SHR_PAGE_CACHE_SIZE_KB = 500000; SHR_TARGET_FREE_FRAME_COUNT = -1; SHR_WELL_KNOWN_PORT_NUMBER = 0; (vmGc spaceSizes: eden init 2048K max 37504K , survivor init 448K max 6272K, vmGc old max 149952K, code max 40000K, perm max 20032K, pom 10 * 16704K = 167040K, vmGc remSet 4036K, meSpace max 191360K oopMapSize 1048576 ) _____________________________________________________________________________ | GemStone/S64 Object-Oriented Data Management System | | Copyright (C) VMware, Inc. 1986-2012 | | All rights reserved. | | Covered by U.S Patents: | | 6,256,637 Transactional virtual machine architecture | | 6,360,219 Object queues with concurrent updating | | 6,567,905 Generational Garbage Collector. | | 6,681,226 Selective Pessimistic Locking for a Concurrently Updateable Database +-----------------------------------------------------------------------------+ | PROGRAM: topaz, Linear GemStone Interface (Linked Session) | | VERSION: 3.1.0.2, Beta Wed Nov 28 16:23:21 2012 | | BUILD: gss64_3_1_0_x_branch-29651 | | BUILT FOR: x86-64 (Linux) | | MODE: 64 bit | | RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue | | Feb 19 12:18:21 UTC 2013) 2002MB | | PROCESS ID: 1324 DATE: 03/21/13 17:52:39 CET | | USER IDS: REAL=dario (1000) EFFECTIVE=dario (1000) | _____________________________________________________________________________ | GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone | |_____________________________________________________________________________| neither .topazini nor $HOME/.topazini were found topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> [Info]: LNK client/gem GCI levels = 851/851 [Info]: libssl-3.1.0.2-64.so: loaded [Info]: User ID: DataCurator [Info]: Repository: working [Info]: Session ID: 8 [Info]: GCI Client Host: <Linked> [Info]: Page server PID: -1 [Info]: Login Time: 03/21/13 17:52:39.997 CET [Info]: libicudata-3.1.0.2-64.so: loaded [Info]: libicuuc-3.1.0.2-64.so: loaded [Info]: libicui18n-3.1.0.2-64.so: loaded Gave this VM preference for OOM killer, Wrote to /proc/1324/oom_score_adj value 250 [03/21/13 17:52:40.001 CET] gci login: currSession 1 rpc gem processId -1 OOB keep-alive interval -1 successful login topaz 1> topaz 1> topaz 1> topaz 1> [20 sz:0 cls: 76289 UndefinedObject] nil topaz 1> topaz 1> topaz 1> topaz 1> GemStone Smalltalk Compiler Errors: | count | true "enable for remote breakpoints and profiling" ifTrue: [ GemToGemAnnouncement installStaticHandler. Exception installStaticException: [:ex :cat :num :args | BreakpointNotification signal. * ^1 ******* "needed to avoid infinite loop when resuming from a breakpoint" ex _incrementBreakpointsToIgnore. ] category: GemStoneError number: 6005 "#rtErrCodeBreakpoint" subtype: nil. 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 "#rtErrSignalAbort" subtype: nil. System enableSignaledAbortError. "This thread is needed to handle the SigAbort exception, when the primary thread is blocked. Assuming default 60 second STN_GEM_ABORT_TIMEOUT, wake up at 30 second intervals." [ [ true ] whileTrue: [ (Delay forSeconds: 30) wait ]. ] forkAt: Processor lowestPriority. count := 0. [true] whileTrue: [ [ "run maintenance tasks" WAGemStoneMaintenanceTask performTasks: count. "Sleep for a minute" (Delay forSeconds: 60) wait. count := count + 1] on: Error, Halt, BreakpointNotification do: [:ex | System inTransaction ifTrue: [ DebuggerLogEntry createContinuationLabeled: 'MTCE continuation'. System commitTransaction. System beginTransaction ] ifFalse: [ System beginTransaction. DebuggerLogEntry createContinuationLabeled: 'MTCE continuation'. System commitTransaction]. ex isResumable ifTrue: [ex resume]]]. 1: [1031] undefined symbol topaz > exec iferr 1 : where Stack is not active topaz 1> topaz 1> [268 sz:0 cls: 68097 Boolean] true topaz 1> [Info]: Logging out at 03/21/13 17:52:40 CET Thanks, for any considerations, Dario |
Re: Restart in automatic the gem when it go down
|
|
Dario,
Sounds good ... I'm glad we're getting there, finally:) The class BreakpointNotification is only used in 2.4.x, so you are using a startMaintenance30 script from a 2.4.x distribution ... you probably need to modify the startMaintenance30 script from your 3.0 product tree... Dale ----- Original Message ----- | From: "Dario Trussardi" <[hidden email]> | To: "GemStone Seaside beta discussion" <[hidden email]> | Sent: Thursday, March 21, 2013 10:34:44 AM | Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down | | Ciao, Dale | | thank to you and Tobias. | | Today i run the Monty ./setupAll.sh | | the script go well. | | | The only doubt is relative to | | > bootGemstone_start links the GemStone/S startup files in /etc/init.d to | > appropriate | > locations in /etc/rc<n>.d for a Ubuntu based GemStone appliance. | > You may want to change the destination names for your system. | > Shall I continue? (Y/N) | > y | > ln: creazione del collegamento simbolico "K05topaz" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "K07statmon" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "K10gemstone" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "K20netldi" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "K05topaz" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "K07statmon" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "K10gemstone" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "K20netldi" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "K05topaz" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "K07statmon" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "K10gemstone" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "K20netldi" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "S95gemstone" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "S96netldi" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "S97statmon" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "S98topaz" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "S98glass_ip_address" non | > riuscita: File già esistente | > ln: creazione del collegamento simbolico "S95gemstone" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "S96netldi" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "S97statmon" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "S98topaz" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "S98glass_ip_address" non | > riuscita: File già esistente | > ln: creazione del collegamento simbolico "S95gemstone" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "S96netldi" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "S97statmon" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "S98topaz" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "S98glass_ip_address" non | > riuscita: File già esistente | > ln: creazione del collegamento simbolico "S95gemstone" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "S96netldi" non riuscita: File già | > esistente | > ln: creazione del collegamento simbolico "S97statmon" non riuscita: File | > già esistente | > ln: creazione del collegamento simbolico "S98topaz" non riuscita: File già | > esistente | | when i redo : sudo bash ./setupAll.sh ( i dont know what is the purpose of | this file ) | | | | | NOW i can manage the bin gemstone_start and the gemstone_stop command | | GemStone status: | Status Version Owner Pid Port Started Type Name | ------- --------- --------- ----- ----- ------------ ------ ---- | OK 3.1.0.2 dario 16108 45299 mar 21 14:54 Stone working | OK 3.1.0.2 dario 11242 50379 mar 21 14:38 Netldi 50379 | OK 3.1.0.2 dario 16110 46178 mar 21 14:54 cache | working~216579baf3f40c0 | | | | | | I have a problem with the deamtools gs_maintenance it don't start the | service. | | The relative maintenance_gem.log report : | | _____________________________________________________________________________ | | Configuration Files | | | | | | | | System File: /mnt/ISTDataBase/DTRdbWorking/data/system.conf | | | | | | | | Executable File: | | /mnt/ISTDataBase//opt3102/gemstone/GemStone64Bit3.1.0.2-x86_64.Linux/seaside/data/gem.conf | | Warning: File not found (errno=2,ENOENT, The file or directory specified | | cannot | | be found) | | | | | using defaults. | | | | |_____________________________________________________________________________| | Using GEM_TEMPOBJ_CACHE_SIZE 200000 from -T command line option | _____________________________________________________________________________ | | Gem Configuration Options for process id 1324 | | | | |_____________________________________________________________________________| | | DUMP_OPTIONS = TRUE; | GEM_GCI_LOG_ENABLED = FALSE; | GEM_ABORT_MAX_CRS = 0; | GEM_FREE_FRAME_CACHE_SIZE = -1; | GEM_FREE_FRAME_LIMIT = -1; | GEM_FREE_PAGEIDS_CACHE = 200; | GEM_HALT_ON_ERROR = 0; | GEM_KEEP_MIN_SOFTREFS = 0; | GEM_MAX_SMALLTALK_STACK_DEPTH = 1000; | GEM_NATIVE_CODE_ENABLED = FALSE; | GEM_PRIVATE_PAGE_CACHE_KB = 960; | GEM_PGSVR_COMPRESS_PAGE_TRANSFERS = FALSE; | GEM_PGSVR_FREE_FRAME_CACHE_SIZE = -1; | GEM_PGSVR_FREE_FRAME_LIMIT = -1; | GEM_PGSVR_UPDATE_CACHE_ON_READ = FALSE; | GEM_RPC_KEEPALIVE_INTERVAL = 0; | GEM_RPCGCI_TIMEOUT = 0; | GEM_RPC_USE_SSL = TRUE; | GEM_SOFTREF_CLEANUP_PERCENT_MEM = 50; | GEM_TEMPOBJ_AGGRESSIVE_STUBBING = TRUE; | GEM_TEMPOBJ_CACHE_SIZE = 200000; | GEM_TEMPOBJ_MESPACE_SIZE = 0; | GEM_TEMPOBJ_OOPMAP_SIZE = 0; | GEM_TEMPOBJ_SCOPES_SIZE = 2000; | GEM_TEMPOBJ_POMGEN_SIZE = 0; | GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE = 90; | GEM_TEMPOBJ_POMGEN_SCAVENGE_INTERVAL = 1800; | CFG_GEM_TEMPOBJ_START_ADDR not used on this platform | LOG_WARNINGS = TRUE; | SHR_NUM_FREE_FRAME_SERVERS = -1; | SHR_PAGE_CACHE_LOCKED = FALSE; | SHR_PAGE_CACHE_NUM_PROCS = 4089; | SHR_PAGE_CACHE_NUM_SHARED_COUNTERS = 1900; | SHR_PAGE_CACHE_PERMISSIONS = 660; | SHR_PAGE_CACHE_SIZE_KB = 500000; | SHR_TARGET_FREE_FRAME_COUNT = -1; | SHR_WELL_KNOWN_PORT_NUMBER = 0; | (vmGc spaceSizes: eden init 2048K max 37504K , survivor init 448K max 6272K, | vmGc old max 149952K, code max 40000K, perm max 20032K, pom 10 * 16704K = | 167040K, | vmGc remSet 4036K, meSpace max 191360K oopMapSize 1048576 ) | _____________________________________________________________________________ | | GemStone/S64 Object-Oriented Data Management System | | | | | Copyright (C) VMware, Inc. 1986-2012 | | | | | All rights reserved. | | | | | Covered by U.S Patents: | | | | | 6,256,637 Transactional virtual machine architecture | | | | | 6,360,219 Object queues with concurrent updating | | | | | 6,567,905 Generational Garbage Collector. | | | | | 6,681,226 Selective Pessimistic Locking for a Concurrently Updateable | | Database | +-----------------------------------------------------------------------------+ | | PROGRAM: topaz, Linear GemStone Interface (Linked Session) | | | | | VERSION: 3.1.0.2, Beta Wed Nov 28 16:23:21 2012 | | | | | BUILD: gss64_3_1_0_x_branch-29651 | | | | | BUILT FOR: x86-64 (Linux) | | | | | MODE: 64 bit | | | | | RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue | | | | | Feb 19 12:18:21 UTC 2013) 2002MB | | | | | PROCESS ID: 1324 DATE: 03/21/13 17:52:39 CET | | | | | USER IDS: REAL=dario (1000) EFFECTIVE=dario (1000) | | | | _____________________________________________________________________________ | | GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone | | | | |_____________________________________________________________________________| | neither .topazini nor $HOME/.topazini were found | topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> | topaz> topaz> topaz> [Info]: LNK client/gem GCI levels = 851/851 | [Info]: libssl-3.1.0.2-64.so: loaded | [Info]: User ID: DataCurator | [Info]: Repository: working | [Info]: Session ID: 8 | [Info]: GCI Client Host: <Linked> | [Info]: Page server PID: -1 | [Info]: Login Time: 03/21/13 17:52:39.997 CET | [Info]: libicudata-3.1.0.2-64.so: loaded | [Info]: libicuuc-3.1.0.2-64.so: loaded | [Info]: libicui18n-3.1.0.2-64.so: loaded | Gave this VM preference for OOM killer, Wrote to /proc/1324/oom_score_adj | value 250 | [03/21/13 17:52:40.001 CET] | gci login: currSession 1 rpc gem processId -1 OOB keep-alive interval -1 | successful login | topaz 1> topaz 1> topaz 1> topaz 1> [20 sz:0 cls: 76289 UndefinedObject] nil | topaz 1> topaz 1> topaz 1> topaz 1> GemStone Smalltalk Compiler Errors: | | count | | true "enable for remote breakpoints and profiling" | ifTrue: [ | GemToGemAnnouncement installStaticHandler. | Exception | installStaticException: | [:ex :cat :num :args | | BreakpointNotification signal. | * ^1 ******* | "needed to avoid infinite loop when resuming from a breakpoint" | ex _incrementBreakpointsToIgnore. ] | category: GemStoneError | number: 6005 "#rtErrCodeBreakpoint" | subtype: nil. | 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 "#rtErrSignalAbort" | subtype: nil. | System enableSignaledAbortError. | "This thread is needed to handle the SigAbort exception, when the primary | thread is blocked. Assuming default 60 second STN_GEM_ABORT_TIMEOUT, wake | up at 30 second intervals." | [ | [ true ] whileTrue: [ (Delay forSeconds: 30) wait ]. | ] forkAt: Processor lowestPriority. | | count := 0. | [true] whileTrue: [ [ | "run maintenance tasks" | WAGemStoneMaintenanceTask performTasks: count. | "Sleep for a minute" | (Delay forSeconds: 60) wait. | count := count + 1] | on: Error, Halt, BreakpointNotification | do: [:ex | | System inTransaction | ifTrue: [ | DebuggerLogEntry createContinuationLabeled: 'MTCE continuation'. | System commitTransaction. | System beginTransaction ] | ifFalse: [ | System beginTransaction. | DebuggerLogEntry createContinuationLabeled: 'MTCE continuation'. | System commitTransaction]. | ex isResumable ifTrue: [ex resume]]]. | | 1: [1031] undefined symbol | topaz > exec iferr 1 : where | Stack is not active | topaz 1> topaz 1> [268 sz:0 cls: 68097 Boolean] true | topaz 1> | [Info]: Logging out at 03/21/13 17:52:40 CET | | | Thanks, for any considerations, | | | Dario | | | | | | | | | |
Re: Restart in automatic the gem when it go down
|
|
Dale, Dario, The https://github.com/Monty/GemStone_daemontools_setup is hold and writing before the Gemstone 3.1 is released The only problem i found is relative to the maintenanceGem30 script component of Monty git release ( copy by ./ setupAll into: ../seaside/bin/ ) As you write it is setup to work only with 2.4 gemstone release. I need to integrate the maintenanceGem30 script with the startMaintenance30 script from a 3.1.0.2 distribution Now all daemontools work well. |
Re: Restart in automatic the gem when it go down
|
|
Dale, i understand ( a minimal ) the scope of rc?.d files and i have do test rebooting the system. As for magic the GLASS environment at restart go well and are ready to manage web request. I don't verify if the down of the system manage correctly the down of Gemstone. The relative log report : > - 03/22/13 12:02:40 CET --- > SHUTDOWN command was received from user DataCurator session 2 gem processId 9073. > > SHUTDOWN command was generated by . > Waiting for all tranlog writes to complete > Waiting for NetRead thread to stop > > Now stopping GemStone. > ======================================================================== > > Terminating stone. > ________________________________________________________________ > It's right ????? In my server ubuntu running some GLASS environment. But from what i understand the Monty daemontools environment can configured only one galss environment. The relative script reference directly the: /etc/default/gemstone creating by ./setupAll.sh and the bash gemstone and topaz into /etc/init.d/ also. These bashs is also call from rc?.d links Anyone have some idea how i can configuring to manage some environment? The daemontools etc/sv and etc/service directory are configurable by /etc/default/gemstone and i think manage by daemontools. The big problem is relative to the rc?.d link. I need to add some rc?.d entry for any specific environment and create all relative etc/init.d script each with specific configuration ? Thanks, Dario |
Re: Restart in automatic the gem when it go down
|
|
In reply to this post by dario trussardi
Dario,
When you fix the scripts, could you issue a pull request for the glassdb fork of daemontools[1] with your updates? Thanks, Dale [1] https://github.com/glassdb/GemStone_daemontools_setup ----- Original Message ----- | From: "Dario Trussardi" <[hidden email]> | To: "GemStone Seaside beta discussion" <[hidden email]> | Sent: Friday, March 22, 2013 4:14:51 AM | Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down | | | Dale, | | > Dario, | > | > Sounds good ... I'm glad we're getting there, finally:) | > | > The class BreakpointNotification is only used in 2.4.x, so you are using a | > startMaintenance30 script from a 2.4.x distribution ... you probably need | > to modify the startMaintenance30 script from your 3.0 product tree... | | | The https://github.com/Monty/GemStone_daemontools_setup is hold and writing | before the Gemstone 3.1 is released | | | The only problem i found is relative to the maintenanceGem30 script | component of Monty git release ( copy by ./ setupAll into: | ../seaside/bin/ ) | | As you write it is setup to work only with 2.4 gemstone release. | | I need to integrate the maintenanceGem30 script with the | startMaintenance30 script from a 3.1.0.2 distribution | | Now all daemontools work well. | | | | |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |