Rayson-
Thanks for the links- I'll add them to my
growing SGE bookmark repository.
Our existing SGE installation was provisioned
by someone who's since left the university.
We wanted to experiment some before we move to
the new version in production. I just started to look
at the upgrade scripts yesterday, with an eye towards
moving our production configuration forward. Cutover
will be interesting (typed with trembling fingers).
Mark
________________________________________
From: Rayson Ho [rayray...@gmail.com]
Sent: Thursday, April 28, 2011 11:59 PM
To: Mark Suhovecky
Cc: users@gridengine.org
Subject: Re: [gridengine users] Supressing csh warning?
Hi Mark,
Good that it's working for you -- I didn't know that you actually
installed a new cluster, instead of doing an in-place upgrade!
In case you are interested in the technical details... you are getting
this behavior because:
- "posix_compliant" is used (which is the default),
- "shell" in queue_conf(5) is set to csh (which is also the default), and
- "csh" is a "login shell" in sge_conf(5).
So SGE decides that it needs to start the script using a login shell
(by passing the "-" flag into csh)
In the csh manpage:
Startup and shutdown
A login shell begins by executing commands from the system
files /etc/csh.cshrc and /etc/csh.login. It then executes commands
from files in the user’s home directory:
first ~/.tcshrc (+) or, if ~/.tcshrc is not found, ~/.cshrc,
then ~/.history (or the value of the histfile shell variable), then
~/.login, and finally ~/.cshdirs (or the
value of the dirsfile shell variable) (+). The shell may
read /etc/csh.login before instead of after /etc/csh.cshrc, and
~/.login before instead of after ~/.tcshrc or
~/.cshrc and ~/.history, if so compiled; see the version shell
variable. (+)
And SGE manpages:
http://gridscheduler.sourceforge.net/htmlman/htmlman5/queue_conf.html
http://gridscheduler.sourceforge.net/htmlman/htmlman5/sge_conf.html
Thus the session sources more startup scripts, and causes the stty
warning message. When unix_behavior is used, then the job environment
does not source as many startup/login scripts, and thus the warning
messages do not appear. ;-D
Rayson
On Thu, Apr 28, 2011 at 8:48 PM, Mark Suhovecky <suhove...@nd.edu> wrote:
> Hi Rayson-
>
> A comparison of the new installion with our old yielded
> a queue attribute, shell_start_mode, which was different.
> I changed its value from "posix compliant" to "unix_behavior",
> and the warning went away. Not sure what this is really doing
> under the hood with ttys and all.
>
> Thanks,
>
> Mark
>
>
> ________________________________________
> From: Rayson Ho [rayray...@gmail.com]
> Sent: Thursday, April 28, 2011 6:59 PM
> To: Mark Suhovecky
> Cc: users@gridengine.org
> Subject: Re: [gridengine users] Supressing csh warning?
>
> It all depends on how the job environment is setup / initiated, and
> traditionally (from the SGE 5.2 days or even earlier?) there needs to
> have a check using "stty -g" before proceeding to run stty commands in
> a batch environment:
>
> http://gridscheduler.sourceforge.net/howto/commonproblems.html#batch
>
> Of course, if we allocate a TTY for the batch job, then this message
> would disappear. But I believe over 95% of the batch jobs do not need
> a real TTY, and just allocate one so that we can make the warning
> message disappear would be overkill.
>
> Can you check if you have any stty commands in your csh startup /
> login scripts??
>
> Rayson
>
>
>
> On Thu, Apr 28, 2011 at 6:49 PM, Mark Suhovecky <suhove...@nd.edu> wrote:
>>
>> I'm testing a new SGE6.2u5p1 installation.
>>
>> Our default shell around here is csh (don't ask me why- explaining will
>> raise my blood pressure).
>> When I submit csh scripts, the following appears in standard out:
>>
>> Warning: no access to tty (Bad file descriptor).
>> Thus no job control in this shell.
>>
>> I've been told that this is a warning csh gives when it's not interruptable.
>>
>> We don't get this error in our SGE6.2u1 environment, so I'm guessing there's
>> a way to
>> suppress this output, but danged if I can figure out how.
>>
>> Any pointers?
>>
>> Thanks,
>>
>> Mark
>>
>>
>> _______________________________________________
>> users mailing list
>> users@gridengine.org
>> https://gridengine.org/mailman/listinfo/users
>>
>
> _______________________________________________
> users mailing list
> users@gridengine.org
> https://gridengine.org/mailman/listinfo/users
>
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
