topic Re: crontab issue... in Operating System - HP-UX

crontab issue...

deCG — Fri, 12 Oct 2007 10:01:17 GMT

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.

Re: crontab issue...

James R. Ferguson — Fri, 12 Oct 2007 10:03:36 GMT

Hi:

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

Regards!

...JRF...

Re: crontab issue...

deCG — Fri, 12 Oct 2007 10:07:27 GMT

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.

Re: crontab issue...

A. Clay Stephenson — Fri, 12 Oct 2007 10:07:59 GMT

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.

Re: crontab issue...

OldSchool — Fri, 12 Oct 2007 10:08:08 GMT

"issues"?

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

Re: crontab issue...

James R. Ferguson — Fri, 12 Oct 2007 10:12:53 GMT

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...

Re: crontab issue...

Geoff Wild — Fri, 12 Oct 2007 10:24:35 GMT

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

Re: crontab issue...

deCG — Fri, 12 Oct 2007 11:09:37 GMT

< 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.

Re: crontab issue...

Bill Hassell — Fri, 12 Oct 2007 12:30:02 GMT

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.

Re: crontab issue...

deCG — Fri, 12 Oct 2007 12:45:29 GMT

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.

Re: crontab issue...

Bill Hassell — Fri, 12 Oct 2007 21:10:50 GMT

> 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.

Re: crontab issue...

Dennis Handly — Sat, 13 Oct 2007 23:10:44 GMT

>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.

Re: crontab issue...

Bill Hassell — Sun, 14 Oct 2007 13:09:17 GMT

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.