any way to give a cronjob a tty?

[Steve Post]

I have a cronjob that starts Sybase. According to sybase, it has a problem because it can't write its tty.
But it's a CRONJOB.
I HAS no tty.

Where can I get one of those?

[Steven E. Protter]

Shalom,

In the batch job:

. /etc/profile
. environment file that includes tty info.

SEP

[Duncan Edmonstone]

I find it unlikely that it MUST have a tty... have you tried redirecting your stdout and stderr to a log file, and redirecting your stdin to /dev/null ?

Can you show your script, plus the output you currently get?

HTH

Duncan

[Steve Post]

The script isn't exactly the problem. It has been working fine for the last 8 years. Sybase has changed. In sybase case #11437433, Sybase support says that now you need to open a new window when starting sybase so it owns its tty. Since there IS no tty, I don't see how I can own it. And without permission to the non-existing tty, the server will go into "blocking mode". This can cause sybase to crash.

So forget about the script. My question is about tty.
Let's call the starting script start_sybase.sh in the script is:
${SYBHOME}/install/startserver -f ${SYBHOME}/install/RUN_TEST 2> /dev/null " &

I log in as user "sybase". I run the script to start Sybase. Things are fine.

If I run the start_sybase.sh script via cron, I have no terminal. It has problems. It has no tty. So it can't send the stdout/stderr to the "console" which is listed from the result of command "/usr/bin/tty."

Now why not just redirect the sybase server process to /dev/null? Sybase says: As far as redirecting std/stderr as a workaround, this is not an acceptable solution for you since Sybase occasionally sends low level unexpected errors to "standard out".

So I am back to making a cronjob look like a human typing stuff. Hence, this forum question.

If I source /etc/profile when logging in via cron? There is something in profile that knows it should not set up a terminal.
Here is the pesky pertinent profile part:
# Be sure that VUE does not invoke tty commands
if [ ! "$VUE" ]; then
# set term if it's not set
if [ "$TERM" = "" -o "$TERM" = "unknown" -o "$TERM" = "dialup" \
-o "$TERM" = "network" ]
then
eval `ttytype -s -a`
fi
export TERM
# set erase to ^H, if ERASE is not set
if [ "$ERASE" = "" ]
then
ERASE="^H"
export ERASE
fi
stty erase $ERASE
# Set up shell environment:
trap "echo logout" 0
fi # if !VUE

I made my own, bogus script called /tmp/junk.
#!/bin/ksh
mytty=`/usr/bin/tty`
/usr/bin/ls $mytty
/usr/bin/date

eval `/usr/bin/ttytype -s -a`
echo "try 2"
mytty=`/usr/bin/tty`
/usr/bin/ls $mytty
/usr/bin/date

I ran it from root's cron via
45 10 * * * su - sybase -c "/tmp/junk"
I put the hyphen in, so it goes through /etc/profile.
But here's my output.
ttytype: couldn't open /dev/tty for reading
stty: : Not a typewriter
Not a terminal
stty: : Not a typewriter
stty: : Not a typewriter
a not found
tty not found
Mon Mar 30 10:45:02 EDT 2009
ttytype: couldn't open /dev/tty for reading
try 2
not not found
a not found
tty not found
Mon Mar 30 10:45:02 EDT 2009
logout

NUTS. Still hitting a wall.

[James R. Ferguson]

Hi Steve:

> If I source /etc/profile when logging in via cron? There is something in profile that knows it should not set up a terminal.

You can add a test for the association of STDIN with a terminal thusly:

...
# Set up the terminal:
if [ -t 0 ]
then
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
tabs
fi

...

Aside from that, I am in agreement with Duncan. It would seem that your crontask could be something like:

# nohup /home/sybase/startup > /var/tmp/sysbase_startuplog 2>&1 &

Regards!

...JRF...

[Steve Post]

The reason why I have not assigned points yet is because I'm running tests right now.

I know when it's hosed I have "switching to blocking mode" in the sybase log.
I know when it's good I have "Setting console to nonblock mode" in the sybase log.

I ran it interactively as user sybase by hand and got the error ALREADY.
I tweeked it a bit and got it working fine...interactively.

I'll let you know what I find after I figure it out via tests.

[jerry1]

Kick it back to the vendor and tell them
to fix their code.

[TTr]

My DBA does not use the startserver command to start the database. Instead he created a one-line script that uses the dataserver command as follows

/path_to_ASE/bin/dataserver -d -e -c -M -s

I don't think we ever ran this in cron but the script exits normally and there are no background processes, everything detaches from the script nicely.

If you are goint to try this in cron ensure that all sybase environment variables are set properly. I think only the -d and -e are really needed all others are default values.

http://manuals.sybase.com/onlinebooks/group-as/asg1250e/util/@ebt-link;pt=8906?target=%25N%15_12549_START_RESTART_N%25

[Steve Post]

I already have sybase12.5 starting/stopping via cron. It's been that way for a very long time.

Making the creator of sybase fix their stuff is a good idea. But they won't fix it. Their resolution does not work because: /usr/bin/tty does not return a terminal. It returns, "not a tty". So it complains that it can't change the permissions on file "not".

I got the script to work perfectly when interactive. And FAIL perfectly when user sybase runs it via cron.

(If this was science fiction, I would reverse the polarity).

[Steven E. Protter]

Shalom again,

I think its just a matter of porting into the start up script what you need from regular environment files.

Pretty much what JRF posted.

SEP