Crontab Help!

[Tony500]

I have a script that I need to have run each night. During its process this script calls another script. I have put the following line into the crontab, but the script did not run last night:

01 21 * * 1-5 /rims/site1/prod1/posftp.sh

Could anyone tell my what is wrong with this crontab entry? The scripts execute properly if started manually, but not if waiting for the crontab. The script involves an FTP process.
Thank you,
Tony

[doug mielke]

cron doesn't source a profile by default. If it runs manually, but int in cron, that's the first place to look.
You may want to post the script to see the script calling script details.

[Kevin Wright]

You may want to check /var/adm/cron/log. Sometimes if your environment is not setup correctly, your script will not run the same as if you were logged in directly in a shell.

[Hai Nguyen_1]

Tony,

There are a few things you can check:
1) Check the mode bit of the script? Can it be executed by the owner of the crontab?

# ll /rims/site1/prod1/posftp.sh

2) Check the syslog /var/adm/syslog/syslog.log to see if the script was executed at 9:01PM last night.

3) If there was any error running the script, the crontab owner should receive email on it.

Hai

[Paul Sperry]

what user is the cron job running under?
check:
/var/adm/cron/cron.allow
and
/var/adm/cron/cron.deny

[A. Clay Stephenson]

Almost certainly this is a problem with PATH or other needed environment variables. Cron intentionally has a very sparse environment so that generally the first few lines of any cron'ed script need to set and export PATH.

The other thing to watch out for is that some commands expect to be running in an interactive environment (i.e. connected to a terminal) --- which cron ain't. You then have to make sure that you have handled i/o redirection properly. It is normally a bad idea to source a users .profile directly or invoke a su - user command from within cron but a plain old su user command is fine because in the latter case the .profile is not sourced. .profiles almost always have command like stty, tabs, ... which expect an interactive environment.

[Kent Ostby]

Tony --

One way to troubleshoot it initially is to put another script in the path of that script and try to login as the user and run it manually.

If the script in question is something that is okay to run during the day then simply run it by itself while logged in as the cron user and see if you get any errors.

The above ideas as well (cron.log) , cron.allow, etc are good places to check.

Also make sure that the commands INSIDE the script have full paths (i.e. instead of 'cat file', put in: '/sbin/cat file').

Best regards,

Kent M. Ostby

[Mel_12]

Tony,

I have read all suggestions on troubleshooting this but nobody asked how the cron job was submitted. Did you simply edit the crontab?

Try logging in as the owner and do:
crontab That is after editing the file. There is a good chance that all other cron jobs scheduled did not run as well.

Cheers,
Mel

[Tim Adamson_1]

Hi Tony,

Now this might sound really dumb, but is the date on your server correct? The crontab entry is set to run Mon thru Fri. If the day is Sat or Sun, it wont run.

Silly, but worth checking all the same.

Tim

[Massimo Bianchi]

Another check: is cron properly running? There were server without a patch that didnt allow for more that 100 cronjob, because of a problem in releasing the shells.

Cron had to be closed and reopened.

But bby far the most probable cause is the lack of a proper environtment.
su - env >> file1
cat /rims/site1/prod1/posftp.sh >> file1
mv file1 /rims/site1/prod1/posftp.sh

Massimo