ksh script works fine but NOT in CRON

[Laurie_2]

Hi All,

How come this k-shell script
I got works fine executed
directly:

#./freespace

But when I put it in cron:

* * * * 1-5 /var/adm/admin/freespace > /dev/null 2>&1

All I get is this output:
Name Tot[MB] Free[MB] Used[MB] Used[%]
with no data...

I'm using an HP-UX 11.0.

I have attached a copy of the
script with the output from
executing directly.

Thanks,
Laurie K.

[Bill McNAMARA_1]

I'd start by suspecting the env.

Add the line
env > /tmp/env

to the script and compare.

I'd also suggest adding /usr/bin/ to every command.

Later,
Bill

[A. Clay Stephenson]

Hi Laurie:

It's not because it's ksh but rather that the environment under cron is intentionally very sparse. You must modify the script so that either everything is called with an absolute path or something like:
PATH=${PATH}:/usr/bin:/sbin:/usr/local/bin
export PATH

This same rule applies to any environment variables that your script is using.

[harry d brown jr]

How is cron supposed to find the command "onstat"??

When using cron, you should ALWAY's use fully qualified path names. And never assume any environmental variable will be available.

live free or die
harry

[S.K. Chan]

Have you try running this as Informix UID rather than running it as root in cron ?

[Sanjay_6]

Hi Laurie,

Seems like the script is unable to execute because it is unable to find the commands you are using to get the output. Suggest sun it as a user,


* * * * 1-5 su - user_name -c "/var/adm/admin/freespace > /dev/null 2>&1"

Hope this helps.

Regds

[Jordan Bean]

It's good to see someone using Informix... Would you also be using Edvanta?

Anyway, as Clay and Sanjay were saying, the default environment is sparse. Your script will either need to be run from an su call to an account with the appropriate environment, or it will need to source/set PATH, INFORMIXDIR, and ONCONFIG, etc itself.

[Frank Slootweg]

Adding to the other responses:

If a script is not supposed to generate output to standard output and standard error, then it is a bad idea to supress such output.

I.e. if you had left off the "> /dev/null 2>&1" from the crontab entry, you would probably have gotten mail with an error message, which would have pointed you to the cause.

So *only* use "> /dev/null 2>&1" if you know the script *will* generate output to standard output and standard error, and you do *not* want that output.