Cron problem

[Joe Short]

I have a script that will synch, and fracture some clones on and EMC CX600. If I run this script interactively as root from the command line, it runs flawlessly. If I run it from root's cron, it fails miserably. Does cron andle scripts any differently than the command line?

[A. Clay Stephenson]

First, cron's environment is intentionally very sparse, including PATH. You need to set and export and needed env vars early in your script. Secondly, you are not connected to a controlling terminal (ie stdout,stdin, and stderr are not associated with a TTY device). If your routines depend upon any interaction or call any routines that do like stty, tabs, tput, tset .. then the routine can fail.

I'm betting on PATH and other environment variables needing to be explicitly set.

[Ken Penland_1]

for the most part yes, but one thing that always gets us is you have to remember that when things run from cron, you dont have any environment variables set....so pathing can be an issue and so on....if you type "env" from command line, and run "env" from cron you will notice they are prob really different...that may be what is causing your script to die

[Pete Randall]

Joe,

The difference is the minimal environment provide by cron, in particular the PATH but also other ENV variables. Either use full path names for all commands in your script or source in a profile at the beginning of the script.


Pete

[Joe Short]

I caught that one, not only am I setting up the env, I am also running command with the complete explicit path in them.
Still no luck.

[Ken Penland_1]

hrm, the only thing I can think of besides env is possibly the shell that it is running in? perhaps your shell is different than what cron uses and it is not specified in your script?

[Pete Randall]

Joe,

Are you getting any errors, either in the cron log or emailed back to your submitting user?


Pete

[Joe Short]

No, no errors, it was looking like a timing issue, so I moved my script's run time around. I expected this thread to be a long shot, but it was worth a try.
I'm going to redesign the script, and see if that brings any better results.

[Cheryl Griffin]

Place "set -x" (without the quotes) at the top of your cron script and run it again. See if the output indicates why it is failing.

[Joe Short]

Cheryl, will that set x work when the script is run from cron?

[Steven E. Protter]

I believe it will work.

It's not a command, its built into the shell.

SEP

[Joe Short]

Excellent, I have my script sscheduled to run again tonight. I'll put that into it right under the shell specification.
Thanks.

[Cheryl Griffin]

>>Cheryl, will that set x work when the script is run from cron? >>

Yes. This is how we troubleshoot scripts, cron scripts.

99% of the time when a script runs from command line and it fails in cron, the environment is not right. When you login, your .profile, /etc/profile, etc. is sourced which sets up your environment. With cron you're in a pseudo environment which means that anything that needs to be set, must be done so in the script.

The set -x should help you determine what's not being set.

[Joe Short]

Thanks, I'll give it a try tonight.