[Glass] gsApplicationTools global environment variables

Hi all,

I am using gsApplicationTools to maintain my maintenance and ZincRest gems.

For testing purposes I setup a second stone and its gemServers would not
start.
It took me a while to realize that during the first install of gsDevKit
some environment variables for logging, the extend and such seem to be
global.
This results in weird situations where e.g. the logs reference the wrong
extend and log files path in the headers, the gem server start scripts
call into the wrong stone and such...

I wasn't able to find any issue reports on that on github, and wonder if
somebody else had these issues, too or if that is meanwhile already fixed.

Thanks
Sebastian
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Sebastian,

I haven't seen this either ... but then I've not looked for it .. could
you submit a github issue with any other specific details you might have
... do you know which global is involved ... any details will help
isolate my search .. off hand I don't recall anything that would lead to
this:)

Dale

On 04/17/2015 08:30 AM, Sebastian Heidbrink via Glass wrote:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

A quick look in the startGemServerGem script shows that there is a stone-specific env var used to control the location of log files:

logDir=${GEMSTONE_LOGDIR}
if [ "${logDir}x" = "x" ] ; then
  logDir=/opt/gemstone/log
fi
logFile="${logDir}/${GemServer}_server-${Port}.log"

The GEMSTONE_LOGDIR is defined $GS_HOME/gemstone/stones/<stone-name>/defStone.env ... this script is run before starting the netldi by th $GS_HOME/bin/startNetldi script ...

If you run the startGemServerGem script from within a gem (using Smalltalk), then the env vars are inherited from the netldi that started the gem.

If you manually start the netldi (and don't use the startNetldi script), you could have had the wrong env vars defined ...

If you run the startGemServerGem script from within a topaz job, the env vars are inherited from the environment from which you started the topaz job.


Finally, if you are manually running startGemServerGem, then it picks up whatever env vars you have set when start the job

You should be able to do `. $GS_HOME/gemstone/stones/<stone-name>/defStone.env` to get the right env vars set ...


Of course you may be refering to some other issue/global:)

Dale

Hi all,

I am using gsApplicationTools to maintain my maintenance and ZincRest gems.

For testing purposes I setup a second stone and its gemServers would not start.
It took me a while to realize that during the first install of gsDevKit some environment variables for logging, the extend and such seem to be global.
This results in weird situations where e.g. the logs reference the wrong extend and log files path in the headers, the gem server start scripts call into the wrong stone and such...

I wasn't able to find any issue reports on that on github, and wonder if somebody else had these issues, too or if that is meanwhile already fixed.

Thanks
Sebastian
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass