Cron jobs are an essential part of most Drupal installations. Cron jobs take care of Drupal maintenance, synchronization, pinging, spam and other important aspects. Every module implements it own cron hook and cron goes and executes the function. It sometimes happens that the cron jobs you’re running fail and you have no idea how. All you get is a blank : "Last cron job did not complete". What should you do?

Usually, it’s a problem with on the modules you recently installed. Most of the time, it’s also accompanied by another PHP error before or after. It’s best to get a long look at the error log, and see whether anything’s wrong. If there are errors, look them up on the Drupal.org site, and if one of the modules is causing it - upgrade it, or report the problem to the development team.

There are many things you can do to debug this problem, but I was looking for an easy solution for one of my not-so-techie colleague.

First, take a look at CronPlus:

CronPlus is meant to relieve application programmers of the need to reinvent the same old wheel of filtering down the Drupal cron calls — which can happen at any interval chosen by the installer — into real-world (approximate) time intervals. CronPlus provides an approximation at each interval. It does not claim, nor even attempt, to be accurate enough for precise applications such as month-end financial processing or real-time control. Instead, it is meant for duties such as routine log cleanup, updating data from external sources, pushing data to other systems, and similar things which require only an approximate time base.

Looking into this issue I came across those two interesting tips. This next tip will give you a more detailed cron message on the module currently being processed:

The flow won’t reach all following cron hook calls and you’ll get the problem you’ve described. The key is to find out which hook_cron is causing the crash, you can do that by adding this in the module_invoke_all() located in includes/module.inc

  foreach (module_implements($hook) as $module) {
    $function = $module .’_’. $hook;

replace it with something like this :

  foreach (module_implements($hook) as $module) {
    if ($hook == ‘cron’)
    watchdog(’cron_runs’, $module);
    $function = $module .’_’. $hook;

You’ll get a new category in the event log called "cron_runs" on your next cron that will list the cron call order. The last one in this list is your culprit. Remember that this is considered core hacking and you should remove the code as soon as you discover the problem location. Core hacking is calling for trouble.

If you’re sure all is working like it should, then another good tip is about playing around with the timeout settings :

Go to your settings.php file (under sites/default or wherever it is). At the bottom of it you will see a list of ini_set commands. Add the following to the list:

ini_set("max_execution_time", 60);

The number at the end is the number of seconds a program can run before timing out. Setting it to 0 means "never timeout" which you should use very carefully, like on a development site where you have control over the server. Try increasing the number at the end until your cron completes.

There is also a way to do this in a .htaccess file (the command is worded slightly differently), but some isps, like mine, have the system set up in a way that will cause a fatal error if you try to control php ini_set from the .htaccess file. As far as I know, you will never go wrong by putting it in the settings.php file.

How do you debug your problematic Drupal Cron jobs?