topic Re: cron $USER; mysterious shell in Operating System - HP-UX

cron $USER; mysterious shell

Vlad_11 — Wed, 01 Oct 2003 14:55:22 GMT

My shell does:
Zip $file.zip $file.
While executing shell from command line, everything is fine (I can see file.zip created and attached in email). However if 100% same shell ran thru cron zip file goes nowhere or doesnâ t created at all, cron log file indicate RC=2.
.
What $USER or group cron running under ? I feel that there is some permission problem or maybe there are some other explanation for this phenomenon.
.
Emaildir is my working dir that holds all files including my shell as shown below.

Thanks. Help !!!!!!!!!

.
drwxrwxr-x 2 root tango 1024 Oct 1 12:44 emaildir

.
-rw-r--r-- 1 tango users 59730 Oct 1 12:44 emaildir_notinpoe.txt
-rw-r--r-- 1 tango users 59730 Oct 1 12:43 emaildir_notinpoe.txt.bkup
-rwxrwxrwx 1 tango users 5650 Oct 1 12:44 emaildir_notinpoe.txt.zip
-rwxrwxrwx 1 tango users 2098 Oct 1 12:44 log
-rw-r--r-- 1 tango users 349 Sep 30 21:00 log.bkup
-rwxrwxr-x 1 root tango 3385 Oct 1 12:41 proc
-rwxrwxr-x 1 root tango 41 Sep 22 10:51 subj
-rwxrwxr-x 1 root tango 3288 Sep 30 11:54 xproc

Re: cron $USER; mysterious shell

Brian Bergstrand — Wed, 01 Oct 2003 14:59:20 GMT

Make sure your script cd's to your working directory. Cron will default to your home directory when it runs the script.

Alternatively use full paths to your files.

Error 2 is ENOENT - No such file or directory. So your file can't be found because you are not in the right directory.

HTH.

Re: cron $USER; mysterious shell

Vlad_11 — Wed, 01 Oct 2003 15:04:51 GMT

Yes, I do cd $WDIR all the time.

Re: cron $USER; mysterious shell

Dave La Mar — Wed, 01 Oct 2003 15:08:27 GMT

Vlad -
Most often it is a lack of full path specifcation. This is seen so often, that the script executes fine outside of cron. If you are executing a script, insure full paths are defined for your script contents, i.e. file locations, commands, etc.

Best of luck.

Regards,
dl

Re: cron $USER; mysterious shell

Patrick Wallek — Wed, 01 Oct 2003 15:09:14 GMT

The user cron runs under depends on the user whose crontab contains the job. If you use root's crontab, then all jobs will run as the root user.

When things work correctly from the command line but not from cron the problem is almost always an environment problem. cron by design has a very sparse environment. Your .profile does NOT get sourced by cron so no environment variables that may be set up through it will be there. Your best bet is to create an environment script that you source from the script your run from cron. In your environment script you should set your PATH, SHLIB_PATH, and any other variables you may need.

In addition I highly recommend using the FULL path to any commands you use. That way you are absolutely sure about exactly what is running.

Re: cron $USER; mysterious shell

Brian Bergstrand — Wed, 01 Oct 2003 15:10:22 GMT

Do you set WDIR in your script? If not, then it is not defined in your cron environment and the cd will fail. For best results, explcitly cd to your path or use full paths.

HTH.

Re: cron $USER; mysterious shell

Vlad_11 — Wed, 01 Oct 2003 15:26:11 GMT

Yes, defenetely I have defined WDIR=/xxx/xxx/
and now I'm using a complete path to files even making cd $WDIR
.
Just made very clear test: cp similar shell that works fine and produces .zip file into
my WDIR, changed WDIR variable, changed cron to point to WDIR/proc ,tried to run and got same bad results: zip and gzip files cannot be created, cron log file has rc=2.
.
Don't have any idea. Will keep you posted.

Thanks to all.

Re: cron $USER; mysterious shell

Bill Hassell — Wed, 01 Oct 2003 15:39:51 GMT

VERY IMPORTANT: cron does NOT login. Therefore, NOTHING from your normal login environment is setup from /etc/profile and .profile so you do not the normal PATH or virtually anything else. The very easiest way to check a cron job that runs fine from an interactive shell is to trace the script. But first: EVERY shell script must start with the required interpreter, like this:

#!/usr/bin/sh

(or #!/usr/bin/ksh or #!/opt/perl/bin/perlm whatever) The reason is that you don't want an arbitrary shell to run your script. You want the correct one (remember, cron does not login). Now to trace the results, add this as the second line after the interpreter line:

set -x

(this assumes your shell is the POSIX shell, or ksh or even bash, but not csh where everything is different). Now run yur script and direct the results into a file:

/path_to_script/myscript 1>/var/tmp/trace1 2>&1

then change cron's entry to the same as above (after the time schedule values) except change trace1 to trace2. Then compare the results.

BTW: I notice 777 permissions on emaildir_notinpoe.txt.zip and log. Usually this means that someone is trying to solve permission issues with a shotgun. I doubt that emaildir_notinpoe.txt.zip or log are runnable programs so execute should not be set at all, and sine writability fir the world is set, anyone logged in can trash your files. Be very cautious with 666 and 777 permissions--they are very seldom correct or what is desired.