Hi guys,
I am trying to be a bit more strict in file permissions for my stones. When I now try to start a stone, I get this error: startstone[Info]: GemStone version '3.1.0.6' startstone[Info]: Starting Stone repository monitor 'debrisTesting2'. startstone[Info]: GEMSTONE is: '/opt/gemstone/product'. startstone[Info]: GEMSTONE_NRS_ALL is: '#dir:/somePath/data#log:/somePath/log/%N%P.log'. startstone[Info]: GEMSTONE_SYS_CONF=/somePath/etc/system.conf GEMSTONE_EXE_CONF=/somePath/etc/gem.conf _____________________________________________________________________________ | ERROR: chdir(/home/marianopeck/) failure: | | System Error: errno=13,EACCES, Authorization failure (permission denied) |_____________________________________________________________________________| startstone[Error]: Stone process (id=25917) has died. startstone[Error]: Could not show end of log file '/somePath/log/log.txt' because: errno=2,ENOENT, The file or directory specified cannot be found So it looks like it cannot create '/somePath/log/log.txt'. The stone is launched this way as part of a larger script. su $RUNASUSER -c '$GEMSTONE_INSTALLATION/bin/startstone -z $GEMSTONE_SYS_CONF -l $APPLICATION_LOG_DIR/log.txt $APPLICATION_NAME > $GEMSTONE_LOGDIR/startup.log 2>&1' And then that script is invoked with sudo from my username marianopeck.. What I don't understand is why it cannot create the log and why it does a " chdir(/home/marianopeck/) " Finally...if from comand line I do: sudo su $RUNASUSER -c " touch '/somePath/log/log.txt' " I can create it with no problem. Any idea what could be happening? _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Okay, there are several things going on here ... first off, we don't recommend that you have GEMSTONE_NRS_ALL set in your startstone environment ... in 3.1.0.6 GEMSTONE_NRS_ALL is not consistently applied and in 3.2.3 and beyond the GEMSTONE_NRS_ALL will be ignored by the startstone command. We recommend that you use `-l` to set the log location for the stone, as you are doing...
The GEMSTONE_NRS_ALL isn't directly involved, but it does tend to confuse things ... We haven't reproduced your problem here, but we believe that the problem is related to the fact that when you use `su username` the "current environment is passed to the new shell" and startstone is probably cd'ing to $HOME which is /home/marianopeck/. You should try using `su --login username` as the environment for the new shell is "similar to what the user would expect had the user logged in directly" and startstone will cd to the $HOME for `username`. Let's see how that works... Dale On Wed, Sep 17, 2014 at 9:32 PM, Mariano Martinez Peck via Glass <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Thu, Sep 18, 2014 at 2:18 PM, Dale Henrichs <[hidden email]> wrote:
Ok, I will remove it then.
Well..the strange thing is that BEFORE I run the startsone I source a file with all the variables I export for that site. And one of the things I export is: export HOME=/somePath I mean...I export $HOME to the correct place where the stone is and where the user I then su do have access. So at the time I run: su -m $RUNASUSER -c '$GEMSTONE_INSTALLATION/bin/startstone -z $GEMSTONE_SYS_CONF -l $APPLICATION_LOG_DIR/log.txt $APPLICATION_NAME > $GEMSTONE_LOGDIR/startup.log 2>&1 ' I must have (and I have just checked) the correct $HOME. So I still don't understand why the startstone would try to read /home/marianopeck.
Yes, but I can't do that because otherwise I lost all the vars of the stone I previously exported. If you see again: su -m $RUNASUSER -c '$GEMSTONE_INSTALLATION/bin/startstone -z $GEMSTONE_SYS_CONF -l $APPLICATION_LOG_DIR/log.txt $APPLICATION_NAME > $GEMSTONE_LOGDIR/startup.log 2>&1 ' if I replace -m for a -l there...all those vars inside the -c will be gone. Now...something I checked...if I fire this stone start scripts not in /home/marianopeck but in /somePath (where the user that runs the stone has access -? $RUNASUSER), then it works perfectly... But it is a pain having to cd there in order to start the stone... Any other idea? maybe startstone is NOT reading $HOME but $PWD ?
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Mariano, I've looked at the c code and when we do a fork we do a chdir() to the `workingDirectory` and throw the error that you see if the chdir() fails.. It looks like startstone does a fork using '.' as the working directory so it is literally using the current directory (i.e., environment variables are involved at all) when it does the fork. you can embed the cd in the -c arg for su, if it makes it any less of a pain: su $RUNASUSER -c "cd /somePath; '$GEMSTONE_INSTALLATION/bin/startstone -z $GEMSTONE_SYS_CONF -l $APPLICATION_LOG_DIR/log.txt $APPLICATION_NAME > $GEMSTONE_LOGDIR/startup.log 2>&1'" Dale On Thu, Sep 18, 2014 at 7:57 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Fri, Sep 19, 2014 at 2:05 PM, Dale Henrichs <[hidden email]> wrote:
OK, you needed to go deep to look. I appreciate your dedication! At least we have an explanation now :)
Exactly. That's what I ended up doing. And since all my scripts pass that line in order to start stone and netlid...just 2 little changes were enough to fix everything. Thanks Dale.
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Dale, I am reviving an old thread. I quote your most important part: ----- "I've looked at the c code and when we do a fork we do a chdir() to the `workingDirectory` and throw the error that you see if the chdir() fails.. It looks like startstone does a fork using '.' as the working directory so it is literally using the current directory (i.e., environment variables are involved at all) when it does the fork. " ----- As you know, after I create a stone via `createStone` I do: sudo chown -R $gsDevKitUser:$stoneOSUser $GS_HOME/server/stones/myStone And then, all the starts/stops of stone, netldi and gems are triggered with the OS user $stoneOSUse. So far so good. But I have 2 scenarios: 1) Me (a sysadmin) logs into the system with a given OS user. Say you are ate /home/mariano. You do "sudo su $stoneOSUse" and then try to start stone. That will fail, becasue current dir is "/home/mariano" and $stoneOSUse does not have access to it. So..everything I do this I must do a "cd" to a place that i know it can fork (like $GS_HOME). 2) Monit trying to start/restart my stuff. Same problem. Monit is started by root and the given user $stoneOSUse cannot fork on the current directory. I have been suffering this problem already with my `startAllStones` and `stopAllStones` as well as with my `startSeasideGems`. Anyway, the workaround I did is pretty simple, and it's the place where you do: # set up stone environment pushd $stonePath >& /dev/null source $stonePath/stone.env popd >& /dev/null I added a line "cd $stonePath" before that and everything works correct. I cannot imagine GsDevKit_home code that would break if I change working dir. Maybe there is, but I haven't faced it yet. If you think we are safe and you think this is correct, then I could like to add this to `startStone` and `stopStone` in a issue + PR. Another possibility would be to do it in a much generic place to avoid modifying each script. Say..in `${GS_HOME}/bin/private/shFeedback` we could do "cd $GS_HOME" but maybe too risky ? Thoughts ? On Fri, Sep 19, 2014 at 2:26 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 02/07/2017 06:19 AM, Mariano
Martinez Peck wrote:
I think it's a good idea ... you can get rid of the pushd as well ... I think the changes should be done on a command by command basis ... There are certain commands like startTopaz that could produce arbitrary output files depending upon what code is executed and it may not be desirable to clump them all in the same directory ... it's annoying to have junk dropped into the current directory but it would even more annoying to not be able to control where the files get created ... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |