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

[OldSchool]

ok, so you've got....

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

and you also mention (repeatedly) "/usr/bin/tty".

So: Is the "startserver" noted above a script or an executable?

You said: "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".

What was their resolution? checking w/ /usr/bin/tty???

Why not log to a file, or does it still block?

If "startserver" is a script, this should be fixable, and relatively easily.

[Steve Post]

well I tried JRF's stuff. It didn't work. But perhaps it is merely a problem communicating my problem.

startserver is an executable of sybase's.
It is looking the tty this process has. It is verifying the that process owns that tty. If the cronjob has no tty, the starserver can't write to it. So it starts having problems.

When I run it interactively, there is a tty.
So there is no problem.


i will make it simple..............

IF I have a script that looks like this:
#!/bin/ksh
echo /usr/bin/tty

And I run it as a cronjob,

is there a way it can tell me something like
/dev/pts/6

instead of
"not a tty"

[Steve Post]

Now there is a way to get what I want. A CRAZY way. Make a cronjob interactive?
0. It is Friday at 3pm.
1. I log in as user sybase
2. I run job nohup ./watch_for_junk.sh &
3. I set up a cronjob to make an empty file called /home/sybase/start_it_up.txt at 2am Saturday morning.
4. I get out.
The program ./watch_for_junk.sh is still running and still (maybe?) has a terminal.
The program looks like this.....
#!/usr/bin/ksh
while [ 1 ]; do
if [ -f /home/sybase/start_it_up.txt ] ; then
startserver xxxxxxxxxxxxxxxxxx
...actually there would be tests to see if it is already up.
fi
sleep 300
done
I have a bad feeling about this. I'm expecting some shaking fingers.
I just got that wizard cap. I want to keep it.
What's wrong with this idea?

steve

[James R. Ferguson · Accepted solution]

Hi (again) Steve:

If you run as a crontask (or an 'at' task for that matter), then there is _no_ TTY associated with the process. This is why I used this test:

[ -t 0 ] && echo "I am interactive"

A deamonized process disassociates itself from any controlling TTY so that no signals sent to the initiating TTY process are seen by it.

A 'nohup' as a background job accomplishes some of the same functionally.

Whether or not your process is a shell script or a binary executable should not change the ability to do "nohup ... &",

Regards!

...JRF...

[Steve Post]

OK. I really was wondering where that tty was on the cron.
I'm very surprised that Sybase would have such a goofy bug.

Thank you all for the help. I'll figure some way around my problem.

Steve

[Marlou Everson]

Steve,

What version of Sybase ASE are you having the problem with?

I am curious since we run 12.5.4 in a ServiceGuard environment where scripts su - sybase to start things. The DBAs are working on upgrading to 15.0.x. When I do a ps the TTY for the dataserver processes is a question mark.

Thanks,
Marlou

[George Spencer_4]

The expect programming language can be used to supply a tty to any program/process that requires one. You would need to install Tcl, Tk, and expect; but I find these are worth their weight in gold, and would not be without them. You can then make crontabs run an expect script to start the program/process.

There may be easier options, but we use this method to supply a tty to programs started by inetd.

[Bill Hassell]

We run a very large number ASE-12.5 Sybase databases and have never run into this problem. Sybase is completely off base (so to speak) to require a tty for start/stop operations. Such a requirement would be a showstopper for lights out operations because a reboot would fail just the same way as a cron or batch job. The support answer that someone needs to oversee the startup sequence would be a showstopper for me. I would escalate this issue to the highest level at Sybase as it changes Sybase from an enterprise quality database to a toy, suitable for use ina small lab.

A tty is by definition an interactive (live human with a screen and keyboard). Are they saying you must provide a 24x7 on-call person to watch the screen whenever the database is restarted? Because this is so unusual, I think someone at Sybase has forgotten to tell the support the correct way to handle startserver's need for a real tty.

I'm not sure if Expect will cause a true tty to be be allocated, something where the tty command will return true.

[Dennis Handly]

>/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'm not sure this will help.
If you use "tty -s" it doesn't echo anything. You then can check the exit status and skip the chmod.

[Duncan Edmonstone]

Steve,

The correct way to fix this is to raise it as a bug with Sybase. There is _no_ way they can reasonably expect a database daemon process to always have a tty associated with it. At the very least their code should be checking the return code from tty, not just reading the response back off stdout. This is a bug, plain and simple...

That said, at this stage you need a workaround, and I'm not sure you are going to get one until you figure out *exactly* what startserver is doing.

If this were me I would be installing tusc on this system:

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.9/

And then looking to see how this call to tty is actually made... depending on that, I guess you might be able to alias tty to some other script which feeds something back to startserver, or alternatively create some sort of wrapper for tty which only comes into play when its called from your start script...

There are some options there, but you need to know what startserver is doing - getting tusc is a useful way to do that.

Still think this is a bug though...

HTH

Duncan

[Steve Post]

Ok....
TTr and Marlow. I am at 12.5 going to 15.0.
The error is see in the syslog file is "unable to write to console, switching to blocking mode"
When it runs good it says "Setting console to nonblocking mode".

Greorge Spencer. Getting tk, tcl and expect might solve loads of problems in the long run. I'll look into it this year.

Bill Hassell. I'd give you an 11 in points if I could. I fully agree that sybase should be demoted to TOY status if this is not resolved. There HAS to be a solution from sybase on this. It is too silly not to be the case.

Duncan, I download and tried tusc on the /usr/bin/date command. I feel like a caveman on a spaceship. I will bug sybase first.

[likid0]

you shouldn't need a tty on the cron for a product like Sybase, in any case, I think you could use screen.

For example:

screen -m -d mondoarchive -D -Ow 10 -S /home/mondo/ -T /home/mondo/ -g -E "\"/home/cdaly/GIS/W2K /home/mondo/\"" -9

This uses 'screen -m -d' to "-m -d Start screen in "detached" mode. This creates a new session but doesn't attach to it. This is useful for system startup scripts.

When screen starts, it will be in the background and "detached".

[Dennis Handly]

>tried tusc on the /usr/bin/date command. I feel like a caveman on a spaceship.

start with: tusc -fpea -o tusc.out command args ...

[Steve Post]

Try screen? Not an option. It would work great, except I don't want to get up at 3am Saturday to reattach to the session and interactively work with it.

"start with: tusc -fpea -o tusc.out command args"?
It immediately bombed out. But it doesn't matter. For Hurray! Sybase is not a toy after all.

The answer from sybase:
The message about blocking or non-blocking doesn't matter. In version 15, the message shows up. But it has been this way all along. It just was not noted in the error log file. IF I would have a problem, I would have already seen it years ago. Besides, there is an option to turn off console messages (to that non-existing tty).

And I _c_a_n_ run a file redirect (sound familiar?), to a file via sybase script RUN_.

So I change RUN_DEV15
from:
/home/sybase15/ASE-15_0/bin/dataserver \
-sDEV15 \
-d/dev/vg21a/rlvmast \
-e/home/sybase15/ASE-15_0/install/DEV15.log \
-c/home/sybase15/ASE-15_0/DEV15.cfg \
-M/home/sybase15/ASE-15_0 \
-i/home/sybase15

to:
/home/sybase15/ASE-15_0/bin/dataserver \
-sDEV15 \
-d/dev/vg21a/rlvmast \
-e/home/sybase15/ASE-15_0/install/DEV15.log \
-c/home/sybase15/ASE-15_0/DEV15.cfg \
-M/home/sybase15/ASE-15_0 \
-i/home/sybase15 \
1>>/home/sybase15/syb_console.txt \
2>>/home/sybase15/syb_console.txt