If you want to get the same behavior as your GE 6.2u6 cluster, then I think bash should be taken out from the login_shells.
I look a 5 min look at the code, and I think currently there is no way to do what you want - so best way is to fix the bash profile and/or change the SGE config. BTW, what's in the bash profile that is causing this random job start directory problem?? Rayson On Wed, Feb 1, 2012 at 1:15 PM, Lane Schwartz <dowob...@gmail.com> wrote: > Aha. That explains why I only encounter this problem on GE2011.11, and > not on ge6.2u6. > > Is there a mechanism to allow a user to specify when submitting a job > that the job should NOT be a login shell? Or is the only option to > modify the global value for login_shells &/or shell_start_mode? > > Thanks, > Lane > > > On Wed, Feb 1, 2012 at 1:08 PM, Rayson Ho <ray...@scalablelogic.com> wrote: >> See "login_shells": >> >> http://gridscheduler.sourceforge.net/htmlman/htmlman5/sge_conf.html >> >> (And you may want to see the "shell_start_mode" option.) >> >> A few sites added bash to login_shells, so we added bash to the list >> by default in GE2011.11. >> >> Rayson >> >> >> >> On Wed, Feb 1, 2012 at 1:00 PM, Lane Schwartz <dowob...@gmail.com> wrote: >>> I think the problem is occurring in my .bash_profile. >>> >>> I'm surprised that file is being read, though. Bash should only read >>> .bash_profile if it was invoked as an interactive login shell, or as a >>> non-interactive shell with the --login option. >>> >>> Is SGE supposed to invoke bash as an interactive login shell when the >>> -S /bin/bash flag is provided? >>> >>> Thanks, >>> Lane >>> >>> On Wed, Feb 1, 2012 at 12:58 PM, Rayson Ho <ray...@scalablelogic.com> wrote: >>>> Hi Lane, >>>> >>>> I was away yesterday... I looked at the traces last night - Grid >>>> Engine correctly passed the working directory to the execution side, >>>> and the execution side did not complain. I read the code that handles >>>> changing job directory, and Grid Engine does check for the error >>>> returned by the change directory system call. >>>> >>>> Thus at job start, the working directory is correct, so it is >>>> something else that is contributing to this random directory behavior, >>>> and most likely it is the login scripts and/or shell/profiles like you >>>> said. >>>> >>>> Rayson >>>> >>>> >>>> >>>> On Wed, Feb 1, 2012 at 12:43 PM, Lane Schwartz <dowob...@gmail.com> wrote: >>>>> OK. I have a bit of progress to report. >>>>> >>>>> When I use -S /bin/csh instead of -S /bin/bash, all jobs run in the >>>>> proper directory. So, that makes me suspect that something in my bash >>>>> config may be in play. >>>>> >>>>> Likewise, if I run with -b y all jobs run in the proper directory. >>>>> >>>>> Lane >>>>> >>>>> >>>>> On Tue, Jan 31, 2012 at 4:54 PM, Reuti <re...@staff.uni-marburg.de> wrote: >>>>>> Am 31.01.2012 um 20:51 schrieb Lane Schwartz: >>>>>> >>>>>>> On Tue, Jan 31, 2012 at 2:00 PM, Reuti <re...@staff.uni-marburg.de> >>>>>>> wrote: >>>>>>>> Am 31.01.2012 um 19:51 schrieb Lane Schwartz: >>>>>>>> >>>>>>>>> On Tue, Jan 31, 2012 at 1:12 PM, Reuti <re...@staff.uni-marburg.de> >>>>>>>>> wrote: >>>>>>>>>> Am 31.01.2012 um 18:10 schrieb Lane Schwartz: >>>>>>>>>> >>>>>>>>>>> On Fri, Jan 27, 2012 at 3:42 PM, Rayson Ho >>>>>>>>>>> <ray...@scalablelogic.com> wrote: >>>>>>>>>>>> On Fri, Jan 27, 2012 at 2:49 PM, Lane Schwartz >>>>>>>>>>>> <dowob...@gmail.com> wrote: >>>>>>>>>>>>> I have encountered a problem where sometimes (but not always) my >>>>>>>>>>>>> jobs >>>>>>>>>>>>> ignore the -cwd or -wd flags and run in my home directory instead >>>>>>>>>>>>> of >>>>>>>>>>>>> the specified working directory. I can run the same job multiple >>>>>>>>>>>>> times >>>>>>>>>>>>> launching from the same directory, and sometimes the job correctly >>>>>>>>>>>>> runs from the current directory, and sometimes it runs from my >>>>>>>>>>>>> home >>>>>>>>>>>>> directory. >>>>>>>>>>>> >>>>>>>>>>>> I ran over 100 test jobs and all of them ran in directory >>>>>>>>>>>> specified in >>>>>>>>>>>> -cwd or -wd. How easy is it to reproduce the issue?? Is the home >>>>>>>>>>>> directory on NFS or some kind of network or cluster storage?? >>>>>>>>>>> >>>>>>>>>>> The home directory is mounted via NFS. The correct directory (where >>>>>>>>>>> the jobs are launched from) is also on NFS. >>>>>>>>>> >>>>>>>>>> Do you use automounter or is it a hard mount? >>>>>>>>>> >>>>>>>>>> (/scratch4 is mounted on all the exechosts if I get you right) >>>>>>>>> >>>>>>>>> The /scratch4 directory is hard mounted on all of the hosts. >>>>>>>> >>>>>>>> Do you have any facility to source .bashrc, as by default it's not >>>>>>>> used for submitted jobs (or is it a feature of SoGE?). >>>>>>> >>>>>>> I'm not sure what you mean. When I log in to a normal bash shell >>>>>> >>>>>> Yep. >>>>>> >>>>>> >>>>>>> ~/.bashrc is sourced. When I submit my job I am passing it the -V >>>>>>> flag, so everything in my current environment should be passed to the >>>>>>> job. >>>>>> >>>>>> So, these variables are then just inherited by the job at time of job >>>>>> submission from the actual bash (and not evaluated during runtime of >>>>>> your job again), but obviously recorded in a wrong way or got lost fort >>>>>> other reasons. Is this result result of your investigation? >>>>>> >>>>>> But they would all be set to the default directory of your user id, most >>>>>> likely your home directory one time at login. >>>>>> >>>>>> -- Reuti >>>>> >>>>> >>>>> >>>>> -- >>>>> When a place gets crowded enough to require ID's, social collapse is not >>>>> far away. It is time to go elsewhere. The best thing about space travel >>>>> is that it made it possible to go elsewhere. >>>>> -- R.A. Heinlein, "Time Enough For Love" >>> >>> >>> >>> -- >>> When a place gets crowded enough to require ID's, social collapse is not >>> far away. It is time to go elsewhere. The best thing about space travel >>> is that it made it possible to go elsewhere. >>> -- R.A. Heinlein, "Time Enough For Love" > > > > -- > When a place gets crowded enough to require ID's, social collapse is not > far away. It is time to go elsewhere. The best thing about space travel > is that it made it possible to go elsewhere. > -- R.A. Heinlein, "Time Enough For Love" _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
