** Cron spits out I am not a Typewriter **

[Michael Gretton]

I have always been curious about this. I have a cron that runs an oracle shutdown procedure and cron shoots root an email with this as the output:

ttytype: couldn't open /dev/tty for reading
stty: : Not a typewriter
Not a terminal
stty: : Not a typewriter
stty: : Not a typewriter


Can anyone tell me how to clean this up? Thank you,

Mike

[Justo Exposito]

Hi,

I'd got this too and I suppose that this is because I use the su - oracle command and this execute the oracle's .profile file and in this profile there are the commands:
if [ "$TERM" = "" ]
then
eval ` tset -s -Q -m ':?hp' `
else
eval ` tset -s -Q `
fi
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
and this command are only for the terminal, and when you use the cron the terminal is not online you are doing a batch or background execution.

Regards,

Justo.

[harry d brown jr]

Check /dev/tty, it usually looks like this:

crw-rw-rw- 1 bin bin 207 0x000000 Dec 18 11:28 /dev/tty

Not sure how this helps.

Also, is your shutdown cron script trying to redirect stdin, stdout, and stderr?


live free or die
harry

[Bill McNAMARA_1]

try connecting a typewrite to /dev/tty

I find the cables a little hard to manage.. if you don't position them just right they'll make a terrible racket...

honestly though.. I've seen this a few time and have found it was because of scripts executing too fast..

I'd examine your crontab entries for syntax and examine the scripts a little more closely..

Later,
Bill

[Michael Gretton]

Justo:

I am not using oracle - in my cron. I am running the command:

/sbin/init.d/oracle stop

[Steven Gillard_2]

This is because you're running the ttytype and stty commands from within a cron job. Since there's no terminal associated with the process you will get these errors.

Either avoid using these commands (ie don't source .profile, set up the environment you need in the cron script), or surround the calls to stty and ttytype in .profile with an if statement so they don't get executed when run from cron.

Cheers,
Steve

[Justo Exposito]

Hi Michael,

And into this script you don't have the "su - oracle" command?

Regards,

Justo.

[Robin Wakefield]

Hi Mike,

Sounds like you need to enclose your stty command in an if statement to see if you're in batch mode or not, e.g.

if [ "$PS1" ] ; then
stty ...
...
fi

will only execute the stty if you're running interactively.

Rgds, Robin

[Bill Hassell]

Very common. For any situation where a script runs commands that require an interactive terminal, commands like stty, tabs, tput, ttytype, tset and others, must protect these commands when the session is not interactive.

The most common mistake is in /etc/profile and .profile where many of these commands are located. Using a command like su - username will login and run the profiles. It turns out there is an easy fix however. Find all of the commands that need a 'real' terminal (or in terms of the error messages, a 'typewriter') and wrapper them with an interactive terminal condition.

The easiest way to determine if a session is interactive is the "i" flag in bourne, POSIX, or ksh shells. To see all set flags, use:

echo $-

You may see something like "isum" which is a list of all 'set' parameters. So if the letter "i" appears in the string, the shell is interactive. An alternative way is to test for -o interactive. And just for good measure, you can test tty for true/false. For /etc/profile, I do this for all users with:

if [ -o interactive ]
then
INTERACTIVE=/sbin/true
else
INTERACTIVE=/sbin/false
fi

-- or --

case in $-
*i*) INTERACTIVE=/sbin/true ;;
*) INTERACTIVE=/sbin/false ;;
esac

-- or --

if tty -s
then
INTERACTIVE=/sbin/true
else
INTERACTIVE=/sbin/false
fi

Now in subsequent places in profiles, the state of $INTERACTIVE may be tested as in:

if $INTERACTIVE
then
eval $(/sbin/ttytype -s)
fi

-- or --

if $INTERACTIVE
then
tabs
fi

By putting this infron of all terminal commands, the "not a typewriter" messages can be eliminated. In fact, logfiles can be reduced in size by testing for interactive and then bypassing the copyright message, mailcheck, news and the motd message.

[Sanjay_6]

Hi Mike,

Take a look at the thread below,

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=e8a6702f0c6b676373/screen=ckiDisplayDocument?docId=200000024598163

Hope this helps.

regds

[Roger Baptiste]

hi,

BigBill's response is the best one can get on this. But, since i have faced this problem few times, would like to add my few nickels too.

The problem as the error message shows is due to having interactive stty's in the scripts, they expect terminal input and since it is a cron job, it won't get any and spits those messages. Whenever a job is set to run in cron, it has to be modified/tuned to remove all interactive responses; set FULL paths to commands. A script which works from command line will not necesarily behave the same way from cron.

HTH
raj

[Michael Gretton]

Thank you all for responses. I found out that my Oracle script in /sbin/init.d does do an su - oracle. I need to digest what you all are stating in your suggestions. I will let you know what it is. Another server of mine doesn't do this even though it runs the same script. I suspect the problem in .profile for oracle. but I see that several of you have given me detailed answers...let me check. thank you all

[Michael Gretton]

STEVE:

Can you tell me what if statement I would use? How can I test in a the .profile that it is being run by cron? That would fix my problem.

BTW by getting this error, is it causing problems with my oracle not stopping/starting properly? Or could I really just ignore these errors. I just want them cleaned up so it looks better and that I want to learn more ...

[Michael Gretton]

NEVER MIND I THINK BILL HELPED.....SORRY GUYS/GALS :)

[Michael Gretton]

OKAY I AM STILL GETTING THE TYPEWRITER STUFF. HERE IS MY .PROFILE. What am I doing wrong?



#!/bin/sh
# @(#) $Revision: 72.2 $

# Default user .profile file (/usr/bin/sh initialization).
if [ -o interactive ]
then
INTERACTIVE=/sbin/true
else
INTERACTIVE=/sbin/false
fi
# Set up the terminal:
if $INTERACTIVE
then
if [ "$TERM" = "" ]
then
eval ` tset -s -Q -m ':?hp' `
set -u
else
eval ` tset -s -Q `
fi
fi
if $INTERACTIVE
then
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
fi
# Set up the search paths:
PATH=$PATH:.
export ORACLE_HOME=/opt/oracle/product/7.3.4
PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_SID=hptest
export TNS_ADMIN=/opt/oracle/product/7.3.4/network/admin
# Set up the shell environment:
trap "echo 'logout'" 0

# Set up the shell variables:
EDITOR=vi
export EDITOR

[Stian Havstein]

I had the same problem.

Try and do the same thing in the system default profile (/etc/profile). First add The two lines you have to wrap with the interactive check are:
"eval `ttytype -s -a`" (which gave you the "ttytype: couldn't.." error)
and
"stty erase $ERASE" (which gave the "stty: : Not a typewriter" error).

I tried the simple solution and changed the lines to "eval `ttytype -s -a 2>/dev/null`" and "stty erase $ERASE 2>/dev/null" instead.
That removed the error messages, anyway.

[Wodisch]

Hi,

how about "enclosing" your critical statements with that line first:

if [ -t 0 ]; then

and end it with this line:

fi

FWIW,
Wodisch (how is a little old-fashioned, now and then)

[Dave La Mar]

Mike -
Not sure, but I think this will rid you of the pesky emails:

From the forum, I picked up the tip to send the cron command output as such:

command >/dev/null 2>&1

This has solved all my pesky email problems to date.

Best of luck.

dl