Sure thing. I'll do the same below.
On 05/10/2016 04:54 PM, Mun Johl wrote:
Hi Jesse,
Thanks very much for your reply.
See my inline comments below.
On Tue, May 10, 2016 at 1:37 PM, Jesse Connell <[email protected]
<mailto:[email protected]>> wrote:
Hi Mun,
What's the shell set to for the queue? If I remember right csh is
the default (and it'll use the default if you don't specify -S).
For example:
For our setup "qconf -sconf | grep shell" shows:
shell_start_mode posix_compliant
login_shells sh,bash,ksh,csh,tcsh
[Mun] I get the same results.
Hmm, re-reading the man page for sge_conf, I think it will *always*
start jobs run with those shells as login shells. This might actually
be the opposite of what you're looking for.
and "qconf -sq somequeue | grep shell" shows:
shell /bin/bash
shell_start_mode posix_compliant
*[Mun] Yikes! Here are my results:*
*
*
*shell /bin/csh*
*shell_start_mode posix_compliant*
*
*
*Okay, I'm new to grid config; so does the above imply that the CSH
startup file will be automatically read (if found) for every qsub job?*
It just implies that it'll use /bin/csh as the shell to run the script
under, and that it should not pay attention to a "#!" at the start of
the script (that's for "posix_compliant" start mode). If I remember
right, it uses a login shell (of whatever shell type you're using) for
batch jobs that are submitted using those shells. From some quick tests
just now it looks like even binary jobs are run within a login shell
unless you specifically run it with a shell setting that *isn't* in that
list.
For example, I compiled a tiny program to print the MODULEPATH variable,
and submitted it under bash and zsh
qsub -cwd -S '/bin/bash' -b y ./env
qsub -cwd -S '/bin/zsh' -b y ./env
The bash one shows our usual MODULEPATH, but the zsh one shows (null).
As I understand it, that's because zsh isn't in our list of login shells.
We recently switched the shell from /bin/csh to /bin/bash on each
queue since so few were using csh anyway. This still tries to
source .bash_profile, since it'll be a login shell either way. (Is
that the part that's problematic, though, as opposed to csh vs. bash?)
*[Mun] Yes (if I understand correctly). That is, I don't want the
shell startup file(s) to be read regardless of the configured shell for
the queue. I want qsub to leverage the calling env's variables (thus, I
use 'qsub -V'). Is that possible?
I *think* it should be as simple as removing the login_shell entries,
but I don't have direct experience there. (Has anybody else been
running things that way?) I'm guessing your users could then just
decide for themselves when and where they want to load profile scripts
for particular jobs.
*
*
*Thanks again for the informative reply, Jesse.*
*
*
*-- *
*Mun*
*
*
Sure, I figure I owe it to the list after lurking for so long :)
Jesse
On 05/10/2016 01:30 PM, Mun Johl wrote:
Hi,
I'm running OGS/GE 2011.11p1 on CentOS 6.5 .
I have noticed that for some reason ~/.cshrc is read
automatically for
every qsub command I issue. My default environment is actually
Bash; I
only put a .cshrc in my home dir to test something for a peer
and then I
noticed qsub would read the .cshrc file automatically (which
negatively
affected my jobs).
I do not have a .sge_request file in my home dir nor in the dir from
where I launch qsub. And my qsub options do not include -S .
I've tried various SGE DEBUG LEVELs, but none that I've tried
have left
breadcrumbs as to why ~/.cshrc was being read.
This is driving me crazy, so any insight would be helpful. Yes, I
_could_ just remove the .cshrc file, but others here actually use
csh/tcsh and could be affected by this as well. Therefore, I'd
like to
root cause the issue if possible.
Thanks,
--
Mun
_______________________________________________
users mailing list
[email protected] <mailto:[email protected]>
https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected] <mailto:[email protected]>
https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
