Cron Troubleshooting

Like with any troubleshooting problem you need to collect evidence to discover the root cause.

• To determine what version of  Vixie cron is installed, use the rpm -q cron command on Suse 10 and rpm -qi vixie-cron on Red Hat. For example. For RHEL 5.8 we get:

  # rpm -qi vixie-cron
  Name        : vixie-cron                   Relocations: (not relocatable)
  Version     : 4.1                               Vendor: Red Hat, Inc.
  Release     : 81.el5                        Build Date: Thu 20 Oct 2011 10:06:14 AM EDT
  Install Date: Tue 24 Jul 2012 03:57:18 PM EDT      Build Host: hs20-bc2-5.build.redhat.com
  Group       : System Environment/Base       Source RPM: vixie-cron-4.1-81.el5.src.rpm
  Size        : 643027                           License: distributable
  Signature   : DSA/SHA1, Wed 18 Jan 2012 08:22:59 AM EST, Key ID 5326810137017186
  Packager    : Red Hat, Inc. 
  Summary     : The Vixie cron daemon for executing specified programs at set times.
  Description :
  The vixie-cron package contains the Vixie version of cron.  Cron is a
  standard UNIX daemon that runs specified programs at scheduled times.
  Vixie cron adds better security and more powerful configuration

• To determine if the service is running,  use the command /sbin/service crond status.
• Cron is one of the few daemons that does not require restart when the configuration changed via crontab command.

Then you need to go through the quick checklist:

1. Do you have proper line in crontab? There should be five fields before invocation of the script or program.

2. Are there any errors in standard logs? Check the cron log, usually /var/log/cron.log or /var/log/messages for errors
3. Are you using relative paths? If your cron job is executing a script of some kind, you must be sure to use only absolute paths inside that script.
4. Does you script has executable permissions?  Please be sure the script in question is executable. In the case script is writing to a file or folder, they should better be writable.
5. Was your command ever invoked? Test your entry in crontab by changing the command to something like: echo "this is a test" > somefile  or touch /tmp/test
   For example you can change your invocation line to:

    * * * * * /bin/echo "this is a test" >> /tmp/test`date +"%y%m%d_%H%M"`

   See if it creates files each minute. Then replace /bin/echo "this is a test" back with your command and see what happens.
    

6. Is your command working at all? Sometimes the script was changes and now has errors that prevent its execution. Often your script makes some implicit assumptions about environment which do not hold in case of running from cron. You can check this situation in two steps:
   • Can you run your command from a command line with the "cron PATH" set instead of default and get the desired results? Cronjobs run in a different environment then particular user. For example the PATH is set to minimal number of directories: PATH=/usr/bin:/usr/sbin:/sbin:/bin:
   • Does you script writing anything to STDOUT or STDERR? Check logs using invocation each minute, for example: 

      * * * * * /root/bin/myscript.pl 2>&1 | tea -a /tmp/myscript.log

     Look for errors in the file /tmp/myscript.log
      
7. If your cron job is running as a regular user, is this user allowed to run cron jobs? If a user was not allowed to execute jobs when their crontab was last edited, just adding them to the allow list won't do anything. The user needs to re-edit their crontab after being added to cron.allow before their jobs will run.
8. The "%" character is used as newline delimiter in cron commands. If you need to pass that character into a script, you need to escape it as "\%".
9. Are there any dead.letters? cron usually sends mail when there's a problem; check your mail and also look for ~/dead.letter.