running scripts from cron

[Ryan Kogelheide]

I have a script that runs perfectly when I run it interactively from ksh, but never works from cron. I've been very careful to set up an identical environment and have set the first line of each file to #!/usr/bin/ksh.

I've read the cron and crontab manpages and see no reason why it should not work.

Are there some subtleties here that I'm missing? How does a script run from cron differ from a script run interactively? Are there any limitations?

[Stefan Farrelly]

The PATH variable is completely different when run from cron. In your script to be run from cron set PATH to everything you need and it will run fine.

[Dietmar Konermann]

Hi!

What kind of error do you get from that script? One other difference is that scripts from cron have no controlling tty.

Regards...
Dietmar.

[John Palmer]

Cron doesn't run any of the normal scripts to condition your environment e.g. /etc/profile and .profile.

Try getting cron to run an env command and compare its output to that from env run after you've logged in and you'll see the differences.

Regards,
John

[Tom Geudens]

Hi,
What your typically missing are the environment parameters (oracle stuff for example). You have to set EVERYTHING you need in your script.

Regards,
Tom

[Trond Haugen]

I agrea with Stefan. What you can do is:
Set the PATH in your script.
Source your profile in the script.
Set the path in the crontab entry.
Source the profile in the crontab entry.

The two latter cond be something like:
0 0 * * * PATH=$PATH:/mypath;/home/trond/cronscript

0 0 * * * /home/trond/.profile;/home/trond/cronscript

Regards,
Trond

[Ryan Kogelheide]

There are two problems:

The first is with the command line to Oracle's rman. The program always throws an exception like the command line is malformed. I tried asking Oracle when exactly this command line parsing error can occur, but they would not say.

The second error is that the initial script has a while loop processing a list of database instances. When the above error occurs within a second shell script, I end the script with a "return" and the first script ends the while loop instead of continuing to the next instance.

I've checked the script and environment very carefully using set -x and echos and all seems to be as expected.

If cron has no tty, what effect does this have?

[Dietmar Konermann]

Hi!

A neat trick if the cronjob problem is env or rlimit related is to use at(1) instaed. The job is also run by cron, but the runtime environment is prepared before.

So as a test:

# echo 'schriptname' | at now

If you have no controlling tty then several command (like stty(1) fail). Also most tty-related ioctl's are failing with ENOTTY (see termio(7)).

Impact of this depends... sometimes problems are cured by aggressively redirecting stdin/stdout/stderr to some files.

Regards...
Dietmar.

[bjs144]

Within the script slot in:-

. ~username/.profile

This will load the .profile and really really help

[Martin Robinson]

There is another quirk in cron, described in small print in the man page. If the command line in cron includes %, it is treated as a new line. This may give the 'malformed command' error.

[Carlos Fernandez Riera]

THe PATH, env and tty tipical issues are described yet in this thread.


A non interactive shell will exit if it detect any error ( see man ksh :

-e If the shell is non-interactive and if a
command fails, execute the ERR trap, if
set, and exit immediately. This mode is
disabled while reading profiles. )



I use to include
set -x
exec 2>/tmp/cronjob.err

while debugging on the begining of the script files, just after #!/usr/bin/ksh.

Now run you job and compare this file agians you interactive ksh -x.

also you can Check /usr/lib/cron/log file for status of the jobs:
> root 24794 c Wed Aug 14 02:00:00 MEST 2002
< root 24794 c Wed Aug 14 05:08:15 MEST 2002 rc=1



rc=1 = return code 1.


HTH

[Jack Werner]

Hi there,
It's a good idea to source the crontab user's .profile or .login or .cshrc file within the script that cron is spawning. This way the user's environment will be properly set when the script runs. It is also a good idea to redirect standard out and error out to /dev/null on the line in crontab that launches your script, so no noise messages will clutter up the system console.

[Ryan Kogelheide]

I still have the problem when rman runs, so I'm posting the whole script set for anyone who has the patience to wade through it. I'm no sh expert and perhaps it's not the best coding...

The rman error is:

Backup failed for c7t6

--------------------------------------------------------------
performing exec1 bak.sh c7t6
ksh -c . /home/oracle/rman/bak.sh c7t6
.........................
Backing up instance c7t6
.........................
rman target=/ catalog=rman/rman@c7r1 cmdfile=/home/oracle/tmp/bak.rman log=/u06/backup/log/bak_c7t6_20020823.log

Argument Value Description
-----------------------------------------------------------------------------
target quoted-string connect-string for target database
rcvcat quoted-string connect-string for recovery catalog
debug none if specified, activate debugging mode
cmdfile quoted-string name of input command file
msglog quoted-string name of output message log file
trace quoted-string name of output debugging message log file
append none if specified, msglog opened in append mode
nocatalog none if specified, then no recovery catalog
-----------------------------------------------------------------------------
Both single and double quotes (' or ") are accepted for a quoted-string.
Quotes are not required unless the string contains embedded white-space.

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00552: syntax error in command line arguments
RMAN-01005: syntax error: found "auxiliary": expecting one of: "all, backup, change, connect, full, force, identifier, k, nocatalog, obsolete, plsql"
RMAN-01007: at line 2 column 1 file: command line arguments

[Paula J Frazer-Campbell]

Hi

crontab calls
Backall :-

#!/usr/bin/sh
#################################################
#
# bakall: stub for calling bakall.sh from cron
#
#################################################
/usr/bin/ksh -c ". $HOME/rman/bakall.sh"


$HOME is not defined.

Paula

[Ryan Kogelheide]

Paula,

cron defines $HOME.

(but thanks for looking at this mess :) )

Ryan

[Leif Halvarsson_2]

Hi

I had a look at your scripts.
As I understand bak.sh works if it is started interactive but not if started by cron.

bak.sh creates a rman sript and starts rman with this script.

What happens if you run the rman script which is created from bak.sh run by cron and run this "cron created" rman script interactive from rman.

Is it any difference in this rman scripts if it created from a interactive bak.sh or from a bak.sh started by cron ?

[Ryan Kogelheide]

Leif,

Thanks for looking at this.

I checked the created rman scripts as well (I opened an iTAR with Oracle and they made me jump through hoops checking things like this and then refused to help me with the problem because they saw it as a shell programming problem).

I kept a copy of all of the scripts as they appeared and then ran them one by one and they worked.

Ryan

[Ryan Kogelheide]

Leif,

But it's true that I've never tried just running the rman direct from cron.

I think a good immitation would be to run a.sh from crontab where a.sh is a bourne shell and it runs b.sh which is ksh which then runs the rman script direct...

I'll play with that.

Ryan