[X-Unix] Cron jobs not running, how to log cron

[William H. Magill]

On 16 Jun, 2004, at 21:48, David Haines wrote:
> I've setup two cron jobs to run , setup as root and set to run as 
> root, on a
> 10.3.3 OS X Server machine.
>
> The permissions for the scripts called by the crontab are set for 
> read,write
> & execute for root user only, and I can invoke the scripts manually as 
> root.
>
> But the cron job does not run.
>
> When I added these jobs to the crontab, there was no error message 
> either.
>
> Here's the listing (crontab -l) :
>
> 45      1       *       *       *       root    /etc/ditto_daily.sh
> 15      0       *       *       1,2,4,6 root    /etc/junkmailcleanup.sh
>
>
> The permissions for the first script:
>
> -rwx------  1 root  wheel  1005  8 Apr 11:51 /etc/ditto_daily.sh
>
> Please tell me the stupid and obvious thing I'm overlooking, and how 
> you
> would go about logging the results of cron jobs... In order to look
> for/track down errors or problems

Yup, you probably are ...

First, define "not-running" --

           grep -i cron /var/log/*
If there are entries somewhere in the /var/log files of the form:

CRON[nnnnn]: (root) CMD (/etc/ditto_daily.sh)

Then cron is running your script. It is your script which is failing.

The usual problem with cron jobs is the path -- Cron INTENTIONALLY does 
not include any of the normal, expected  environmental variables.  It 
is a security feature. This is why scripts which run from "your 
account" work fine, but don't work when you run them from cron. You are 
making invalid assumptions about the environment.

OS X (1.3.4)'s default /etc/crontab defines ONLY:

SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log

Anything else you want must be added in the script you are trying to 
run.

Alternately, specify complete path names for everything -- which is a 
good idea from a security point of view anyway.  This means including 
"commands" like "mv" as /bin/mc "cp" as
/bin/cp, etc.

One trick I use is to simply define a "/etc/profile-cron" which is 
included as the first line of every cronjob. In this I set the path, 
and similar things for the environment I plan to use via:

". /etc/profile-cron"

This is the scheme used by the system with the normal periodic tasks -- 
the first line in the file sources "/etc/defaults/periodic.conf"

Cron itself does not provide any useful logging information for things 
like this -- you have to build it into your script... (mainly because 
cron is working fine, it's your script that is failing.)

Change your crontab entry to something like:

45  1 * * *    root    /etc/ditto_daily.sh > /var/log/ditto.out 2>&1

/var/log/ditto.out will then contain any error messages.

Of course, you probably then also need to add:

set -x
and or
set -xv

So that you can actually tell what command the resulting errors belong 
to.

And make certain that there is a blank line after the last entry in the 
/etc/crontab.
(I.e. a cr/lf at the end of the last data line.)

I always end the file with a single "#" to guarantee the actual crontab 
entry is read.

As a good educational exercise create a file: /usr/local/adm/crontest2 
(or whatever)

      #!/bin/sh
      set -x
      printenv
      #

chmod it to execute.

and run it as above:
45  * * * *    root    /usr/local/adm/crontest2 > 
/var/log/crontest2.out 2>&1

crontest2.out will then show you what environment your "naked" cron job 
executes in.

Don't forget to delete the entry from crontab after testing.

Also, remember to always pick a time that is at least 2 minutes in the 
future for your test time. This allows cron time to re-read the entries 
and set itself up so that you don't get caught on a clock change that 
you weren't expecting. NOTHING happens instantaneously, despite how 
fast a G5 seems ...!


T.T.F.N.
William H. Magill
# Beige G3 - Rev A motherboard - 768 Meg
# Flat-panel iMac (2.1) 800MHz - Super Drive - 768 Meg
# PWS433a [Alpha 21164 Rev 7.2 (EV56)- 64 Meg]- Tru64 5.1a
# XP1000  [Alpha EV6]
magill at mcgillsociety.org
magill at acm.org
magill at mac.com