[gridengine users] Supressing csh warning?
rayrayson at gmail.com
Fri Apr 29 03:59:48 UTC 2011
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
And SGE manpages:
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
On Thu, Apr 28, 2011 at 8:48 PM, Mark Suhovecky <suhovecky at 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.
> From: Rayson Ho [rayrayson at gmail.com]
> Sent: Thursday, April 28, 2011 6:59 PM
> To: Mark Suhovecky
> Cc: users at 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:
> 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??
> On Thu, Apr 28, 2011 at 6:49 PM, Mark Suhovecky <suhovecky at 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?
>> users mailing list
>> users at gridengine.org
> users mailing list
> users at gridengine.org
More information about the users