crontab issue...

[deCG]

I have both 11.11 and 11.23 servers having cron job issues.

I restarted cron daemon with '/sbin/init.d/cron stop/start'.

And it still doesn't work properly. I was thinking about rebooting servers but I have no downtime.

Please give me a advise. Thank you.

[James R. Ferguson]

Hi:

Define exactly what you mean by "issues". Exactly what isn't working? What are your symptoms?

Regards!

...JRF...

[deCG]

Well I put ignite script to backup OS which is used for all our HPUX servers.
But some of servers' cron job is not working. So I restarted cron daemon a couple of times and it still won't work.
(Actually some servers did work, but some
there are 5 servers not working.)

I hope this describes in more details.

Thanks.

[A. Clay Stephenson]

Well, I would start with something like examining /var/adm/cron/log and looking for clues. It would help if you translate "doesn't work properly" into something a bit more specific.

[OldSchool]

"issues"?

what, they fail? run at wrong time? don't seem to get run?

[James R. Ferguson]

Hi (again):

> Well I put ignite script to backup OS which is used for all our HPUX servers.

So, is it that your script executes correctly if run from a shell commandline but not when 'cron'ed?

Remember, the 'cron' environment is devoid of environmental variables declared in your '.profile' since it is not a login that reads your profile. Your default environment consists only of HOME, SHELL, LOGNAME and PATH and the PATH *only* contains '/usr/bin:/usr/sbin:.'.

Regards!

...JRF...

[Geoff Wild]

For ignite from cron - we found it was better to call a script with your ignite commands inside it.:

0 2 * * 6 /opt/ignite/bin/make_net_recovery_script.sh

#cat /opt/ignite/bin/make_net_recovery_script.sh
#!/bin/sh
/opt/ignite/bin/make_net_recovery -v -x exclude=/var/opt/perf/datafiles -x inc_entire=vg00 -s ignite >/usr/local/logs/net_ignite_log.`date +%y%m%d` 2>&1
/opt/ignite/bin/report_net_ignite_status_creation_image.sh


Rgds...Geoff

[deCG]

< root 11125 c Sun Oct 7 14:59:09 EDT 2007
> CMD: /Admin/Backup/OS_Backup.sh 1>/dev/null 2>/dev/null

This is from the log.

$ /Admin/Backup#more OS_Backup.sh
Back_Home=/Admin/Backup
Back_Log=$Back_Home/Back.log
echo "`date`: OS Backup Started" > $Back_Log
/opt/ignite/bin/make_tape_recovery -AvI -a /dev/rmt/0mn 2> $Back_Home/ignite.log
echo "status:" $? >> $Back_Log
echo "`date`: OS Backup Finished" >> $Back_Log

And this is script which is used on all servers.

But Back_Log never gets updated and no data on ignite.log.

[Bill Hassell]

Your crontab entry:

> ... /Admin/Backup/OS_Backup.sh 1>/dev/null 2>/dev/null

You script is probably trying to tell what is broken but you have thrown everything away into /dev/null. Change the /dev/null redirection to a local logfile like this:

/Admin/Backup/OS_Backup.sh > /tmp/OS_backup.log 2>&1

then run the script using the batch command. This will simulate the crontab environment but it will run immediately. Are you running your make_tape_recovery with -v? This will tell you a lot in the recovery.log file.

[deCG]

OK, I should try that.
But weird thing is that when I run script manually there is no error.

Anyway, I will try that for next OS backup.

Thank you.

[Bill Hassell]

> But weird thing is that when I run script manually there is no error.

Absolutely expected for a script that was not written for the cron/at/batch environments. cron never logs in. When you run the script by hand, you are doing it from a login shell with variables set by several profile scripts.

> Anyway, I will try that for next OS backup.

I would run it now using the batch command rather than cron and if necessary, add the trace option so you can see all the steps completed by the script. To set tracing, add the command: set -x at the top of the script.

[Dennis Handly]

>Bill: Absolutely expected for a script that was not written for the cron/at/batch environments

at(1)/batch(1) guarantees it saves the environment. Of course aliases are lost.
So batch(1) may not be a good simulation for cron jobs.

[Bill Hassell]

Dennis: at(1)/batch(1) guarantees it saves the environment.

Oops, correct. Both at and batch copy the current environment in front of the job. Shell settings that do not get reported in the env command are not established for at and batch.

cron on the other hand provides an absolute minimum environment. From the cron man page:

cron supplies a default environment for every shell, defining:

HOME=user's-home-directory
LOGNAME=user's-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh

Not very much at all. Note that the shell that runs the script will be the POSIX shell /usr/bin/sh so if a different interpreter is needed, be sure that it is on line 1 such as:

#!/usr/bin/ksh

For testing, I would just put echo infront of the actual backup command so the script will run without watinign for the tape. Then put the script into crontab to run very soon. Add the set -x option to watch execution and don't redirect stdout or stderr.