Gem go down for WAFileLibrary error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Gem go down for WAFileLibrary error

dario trussardi
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?
Reply | Threaded
Open this post in threaded view
|

Re: Gem go down for WAFileLibrary error

Dale Henrichs
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?
Reply | Threaded
Open this post in threaded view
|

Re: Gem go down for WAFileLibrary error

dario trussardi

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?

Reply | Threaded
Open this post in threaded view
|

Re: Gem go down for WAFileLibrary error

Dale Henrichs
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?
|
Reply | Threaded
Open this post in threaded view
|

Restart in automatic the gem when it go down

dario trussardi
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 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


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


Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

Dale Henrichs
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
|
|
|
Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

Tobias Pape
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
Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

dario trussardi
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 



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







Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

dario trussardi
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 



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




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

Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

Tobias Pape
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



Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

dario trussardi


> 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

Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

Tobias Pape
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
>
>
>
>> “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
Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

dario trussardi


> 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


Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

Dale Henrichs
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
|
|
|
Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

otto
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
> |
> |
> |
Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

dario trussardi
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








Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

Dale Henrichs
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
|
|
|
|
|
|
|
|
|
Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

dario trussardi

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.



Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

dario trussardi

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

Reply | Threaded
Open this post in threaded view
|

Re: Restart in automatic the gem when it go down

Dale Henrichs
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.
|
|
|
|
12