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 <[email protected]> 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 [[email protected]]
> Sent: Thursday, April 28, 2011 6:59 PM
> To: Mark Suhovecky
> Cc: [email protected]
> 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 <[email protected]> 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
>> [email protected]
>> https://gridengine.org/mailman/listinfo/users
>>
>
> _______________________________________________
> users mailing list
> [email protected]
> https://gridengine.org/mailman/listinfo/users
>
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
