any way to give a cronjob a tty?

[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