new to unix here, im learning how to schedule jobs with crontab. The following cron job runs under root but not under a test account i created.
50 11 * * 0 /usr/bin/banner "HELLO" > /dev/console
i have no idea with it isn't running under the test account but runs right on time when i create the cronjob under root.can someone please help? thanks.
You might check /var/cron/log to make sure the command's executing. Cron jobs won't run if the account's password has been locked. Also, make sure you're using crontab -e to make changes vs hand editing them. Cron doesn't know about new crontabs files unless you restart the cron process. crontab -e kicks the cron process when you save your changes.
Carl
Thanks for the reply, I checked the log and the error is:
"! could not obtain latest contract from popen(3C): No such process "
I tried a different cron job and it works, it seems this only happens on non-root jobs that produce output.
any help please?
Well now, with an actual error message, you can google the results. I did a quick google and found this interesting topic over on the sun forums:
http://forum.java.sun.com/thread.jspa?threadID=5073270
You might check it out and see if any of the answers there fix your problem.
Carl
I actually saw that forum before my second post here, but found no solution. If anyone else in addition to BOFH, please feel free to chime in.
In general only root has the right to write to /dev/console
could not obtain latest contract from popen(3C): No such process
Got this error when starting a script from cron on Solaris10
Read a lot about it googling around.
Redirecting stdout and stderr to a file (exec 1>/tmp/loglog 2>&1) solved the problem as has been indicated by others; In my case the output was:
"tput: No value for $TERM and no -T specified"
My cron-activated script called another script that uses tput which of course can't do a thing without a TERM...
Which also explained why there was no problem running it manually.
So, it appears to be a bug in cron with handling the output of a script started by it.
If you don't want to or can't wait for patches, redirect stdout/stderr to a file, check the contents of it, solve the problem or, redirect them to /dev/null....
BTW, output on stdout and stderr both cause the same error.
Sun, you should have solved this years ago!
Wait for which patch or which problem to be solved?
There is nothing to be patched or solved.
This is the way it is intended and designed.
A cron job is started without any terminal attached to the process and all its child processes. Therefore TERM is not defined, as it should be.
And therefore the only option to send the output to, either STDOUT or STDERR, is to a file. (/dev/null is a special file).