Running script manually vs within cron = different results

Question

Running Solaris 9 SPARC
Logging in as user oracle (or as root) and running a shell script manually (executing from the command line) everything works, when running the very same shell script from within the oracle crontab file things fail.
I believe I have added to the shell script what is necessary in the way of environment variables, etc. ORACLE_HOME, PATH and export(ed) both
What could the difference be.

Answer 1

Impossible to tell from the information you've gathered so far.
Not working with databases significantly, I don't know what troubleshooting options are best available. Is there some sort of error code that tells you why the operation fails? (permissions? DB error? etc...)
You might run the shell script in the reduced environment under truss, and then truss cron right before it execs the job. I'd recommend:
truss -f -ae -t exec <job> or
truss -f -ae -t exec -p <cron's PID>
That will give you a display of exactly how cron is executing the script. As an example, here's an 'ls' that I invoked:
# truss -f -ae -t exec ls
2165: execve("/usr/bin/ls", 0xFFBFFE1C, 0xFFBFFE24) argc = 1
2165: argv: ls
2165: envp: TERM=xterm SHELL=/sbin/sh SSH_CLIENT=10.245.6.6 4034 22
2165: SSH_TTY=/dev/pts/1 USER=root PATH=/usr/sbin:/usr/bin
2165: MAIL=/var/mail//root PWD=/lib/svc TZ=US/Pacific SHLVL=1
2165: HOME=/ LOGNAME=root
2165: SSH_CONNECTION=10.245.6.6 4034 10.1.1.7 22 _=/usr/bin/truss
2165: OLDPWD=/lib/svc/method
And via cron:
2176: execve("/usr/bin/sh", 0xFFBFDBE0, 0x0002CFAC) argc = 3
2176: argv: sh -c /usr/bin/ls
2176: envp: HOME=/ LOGNAME=root PATH=/usr/sbin:/usr/bin
2176: SHELL=/usr/bin/sh TZ=US/Pacific
2178: execve("/usr/bin/ls", 0x00039F58, 0x00039F60) argc = 1
2178: argv: /usr/bin/ls
2178: envp: HOME=/ LOGNAME=root PATH=/usr/sbin:/usr/bin
2178: SHELL=/usr/bin/sh TZ=US/Pacific
Note that although I put a binary in crontab (/usr/bin/ls), cron doesn't exec it directly. Instead it passes it to /usr/bin/sh to exec. Also we see the reduced environment. I'd have to explicitly reduce my environment to replicate that...
# truss -f -ae -t exec env -i TZ=US/Pacific PATH=/usr/sbin:/usr/bin SHELL=/usr/bin/sh LOGNAME=root HOME=/ /usr/bin/ls
2200: execve("/usr/bin/env", 0xFFBFFDA4, 0xFFBFFDC8) argc = 8
2200: argv: env -i TZ=US/Pacific PATH=/usr/sbin:/usr/bin
2200: SHELL=/usr/bin/sh LOGNAME=root HOME=/ /usr/bin/ls
2200: envp: TERM=xterm SHELL=/sbin/sh SSH_CLIENT=10.245.6.6 4034 22
2200: SSH_TTY=/dev/pts/1 USER=root PATH=/usr/sbin:/usr/bin
2200: MAIL=/var/mail//root PWD=/lib/svc TZ=US/Pacific SHLVL=1
2200: HOME=/ LOGNAME=root
2200: SSH_CONNECTION=10.245.6.6 4034 10.1.1.7 22 _=/usr/bin/truss
2200: OLDPWD=/lib/svc/method
2200: execve("/usr/bin/ls", 0xFFBFFDC0, 0x00023338) argc = 1
2200: argv: /usr/bin/ls
2200: envp: HOME=/ LOGNAME=root SHELL=/usr/bin/sh
2200: PATH=/usr/sbin:/usr/bin TZ=US/Pacific
done!
But that's just a way of looking at differences. Being able to ask the sql script for what error is affecting it may get you the information more directly.
Darren