Regular command

[Ahmed_41]

Dear all,
i need to run a script every 10 min, every day to do a specific job
can someone tell me how to write it in crontab, also how to check the the job runs ?

i did the following, is it right ??

00,15,30,45 * * * * ./opt/OV/bin/pingcheck

:q
warning: commands will be executed using /usr/bin/sh
#

also this warning i got when i quit the crontab -e root what does it mean ?



thanks

[Stephen Keane]

You asked cron to run your command every 15 minutes, not 10 minutes.

The warning is only applicable if

(a) you don't have a #!/bin/ksh or something at the start of your file

(b) running your script using sh is a problem

Otherwise, ignore it.

Did you really mean to do

. /opt/OV/bin/pingcheck

i.e. was the '.' deliberate?

[Keith Bryson · Accepted solution]

Ahmed

Your format is correct. Check /var/adm/cron/log for messages regarding job start/stop. You may also want to re-direct any STDERR/STDOUT to /dev/null to prevent the script output creating mail:

00,15,30,45 * * * * ./opt/OV/bin/pingcheck 1>/dev/null 2>&1

Any script specified will be run using the /usr/bin/sh shell (unless you include an alternative in your script).

All the best - Keith

[Peter Godron]

Ahmed,
your crontab entry is correct to run every 15 minutes. The warning can be ignored unless your pingcheck script relies on a specific shell.
The warning just means that the shell used will be /usr/bin/sh.
Regards

[Ahmed_41]

yes my script starts by
#! /bin/sh

and i am using the ./ cuz when i run my script from a shell i need to do ./script name

so is there any problem with that ?? i mean is there a problem to call my script using the ./ since i do the same when i try to call it from the shell

do you think i shall change the script to start by #! /bin/ksh and why ???

[john korterman]

Hi,
the warning means that your crontab file does not have a line specifying which shell to use, e.g.
#!/usr/bin/sh

you should not start the path to the program with a dot:
./opt/OV/bin/pingcheck
should probably be
/opt/OV/bin/pingcheck
and I would recommend that you redirect output to a file, which can then be checked for errors, e.g.:

0,10,20,30,40,50 * * * * /opt/OV/bin/pingcheck >/tmp/pingcheck.out 2>&1

You should also consider editing your crontab in a separate file, and when satisfied with the file, activate it by executing:
# crontab
to read it in as the current users crontab, but check first with the id command which user you are!


regards,
John K.

[Ahmed_41]

here is the log
i cannot understand did it run or not

# cd /var/adm/cron
# more log
! *** cron started *** pid = 1082 Tue Feb 1 14:49:06 CAT 2005
> CMD: ./opt/OV/bin/pingcheck
> root 2690 c Tue Feb 1 15:15:00 CAT 2005
< root 2690 c Tue Feb 1 15:15:03 CAT 2005
> CMD: ./opt/OV/bin/pingcheck
> root 2728 c Tue Feb 1 15:30:00 CAT 2005
< root 2728 c Tue Feb 1 15:30:13 CAT 2005 rc=127
> CMD: ./opt/OV/bin/pingcheck
> root 2781 c Tue Feb 1 15:45:00 CAT 2005
< root 2781 c Tue Feb 1 15:45:13 CAT 2005 rc=127
#


besdie i am sure it didnot run, cuz if it run it calls another script that do some changes which didnot happen

[Patrick Wallek]

No, your script almost certainly did not run. The rc=127 is the key. That is a error return code.

rc=127 can't fork (this might also be return code from the shell)

Your problem almost certainly is the fact that you have a ./ in front of the command. That will not work. If you command is located in /opt/OV/bin, then just take the . off. If your command is located somewhere else, specify the FULLY QUALIFIED path to the command.

If you want it to run every 10 mintutes it should be:

00,10,20,30,40,50 * * * * /opt/OV/bin/pingcheck

[Keith Bryson]

Looking at the log, the first run took 3 seconds. Both subsequent runs took 13 seconds, but returned a non-zero exit code (check the script). Cron has run the job though.

After each log job entry, a PID is given with a start time on the next line. The PID is then repeated later in the log when the job finishes, with the completion time (with the > < signs showing start or completion).

Keith

[Bill Hassell]

You don't want to use ./ in any crontab entry. cron does not login and therefore, any of your environment (shell variables, ulimit values, etc) are not inherited. Read the man page for crontab where it discusses the cron environment.

Now the reason tht you have to type ./anything is that the full path to your script in not in your current $PATH variable, and that's a good thing, especially for home diretories. But in your pingcheck task, the full path is already present and does not need the leading .

Now if you cannot type just /opt/OV/bin/pingcheck (no leading .) to start pingcheck then somehow, you have the /opt directory in your home directory...very strange. The only login where this would work is if you are logged in as root and your home is / (which isn't a good idea anyway) or you are logged in as a normal user and / is your home (never a good idea). Is /opt mounted from another computer? I would never recommend that for a production system.

The /bin/sh is fine and should be left that way. ksh and sh (the POSIX shell in HP-UX only) are virtually the same. If the script runs OK, just leave the shell command line as it is. NOTE: /bin is not a directory on HP-UX. The correct path is /usr/bin, as it is on many other flavors of SysV Unix. It was changed more than 10 years ago. /bin works because it is a symbolic link, or more accurately, a transition link, designed to make the transition to the V.4 filesystem layout a bit easier.

To see if your cron job runs OK, insert the line: set -x as the second line in your script. When it runs, the entire script will be traced and the output sent to your email address on the HP-UX computer.

[Ahmed_41]

guys,
i did the change i removed the "." and i changed the interval to the one i need

but it is still not working, i get the same things in the log
i would like to mention that this script calls another script from inside it, should i remove also the "." from infront the other script i am calling from inside the main script ??

Thank

[john korterman]

Hi,
you should of course test your command directly on the command line before entering it in crontab.
If the command does not function as expected in crontab - and if you have not redirected command output to a file - then check the mail for the user in question.

regards,
John K.

[Patrick Wallek]

Yes, absolutely! You don't want any './' if you are calling scripts within scripts UNLESS you cd to the appropriate directory first. The best way, though, is to just use fully qualified paths to call scripts and commands.