Home / The S-Files: Cron run exceeded the time limit and was aborted.

The S-Files: Cron run exceeded the time limit and was aborted.

Tech Support Case Studies

Our support team is prepared to deal with any Drupal related problem or question that might arise. Some problems show up more often than others, though, and in those cases it is good to have the solutions at your fingertips.

This recently got added to our growing library of Drupal knowledge, and deals with the problem of running cron efficiently. In the effort to tune PHP to perform well while serving normal web pages, it is possible to set some values in php.ini so low that they are insufficient for running cron.

Two such values are max_execution_time and memory_limit. You want both of these to be as low as you can get away with because then you have more resources available for serving more page views.

This will bite you, though, if you have cron tasks that need extra time or memory. You'll know this is happening because you'll have Cron run exceeded the time limit and was aborted. as an error message in your logs.

The solution, on Ubuntu, Debian, and most other modern Linux distributions, is to take advantage of the fact that there are two php.ini files. One for Apache, and one for CLI (the command line interface). On Debian and Ubuntu these are located at /etc/php5/apache2/php.ini and /etc/php5/cli/php.ini.Tune the apache2/php.ini file for high performance, but tune the cli/php.ini file for having enough available resources to get the large jobs done. Once you've done that you can take advantage of a little known script that ships with Acquia Drupal (Drupal 6), the scripts/drupal.sh script. Here's how you'd invoke it to run cron for you:

/var/www/docroot/scripts/drupal.sh --root /var/www/docroot http://default/cron.php[/codefilter_code]

Let's break that down. The script is found in /scripts in any Drupal 6 installation. So if you have your site in /var/www/docroot, the script will be at /var/www/docroot/scripts/drupal.sh. The --root parameter tells the script where your Drupal docroot is. The final parameter will be "http://default/cron.php". Exactly like I just typed it. Not adjusted in any way to the name of your site, or anything else. Just "http://default/cron.php".

You can try running the script and checking your logs to see if cron is being invoked. Once you've nailed the syntax of running the command, add it to your crontab for regular cron execution:

*/1 * * * * /var/www/docroot/scripts/drupal.sh --root /var/www/docroot http://default/cron.php > /dev/null 2>&1

Comments

Posted on by Django Beatty.

Does this work with multi-site installations?

Posted on by fuerst (not verified).

Even better you can run drupal.sh as parameter to the php binary. This way you are able to feed the php binary with settings without the need to modify any php.ini:

/usr/bin/php -d memory_limit=64M -d max_execution_time=300 /var/www/docroot/scripts/drupal.sh --root /var/www/docroot h ttp://default/cron.ph
[/codefilter_code]
Posted on by Robert Douglass.

Acquian Michael Haag points out that an easier syntax for running the command would be:

     cd /var/www/docroot
    ./scripts/drupal.sh http://default/cron.php
[/codefilter_code]

Robert Douglass
Senior Drupal Advisor, Acquia

Posted on by fuerst (not verified).

That's easier when running at a shell prompt directly. Although not applicable for the purpose of using it in the crontab where you usually want to use a 1 line command.

Posted on by SeanBannister (not verified).

Just have a question about this quote :

Two such values are max_execution_time and memory_limit. You want both of these to be as low as you can get away with because then you have more resources available for serving more page views.

It was my belief that setting these to a minimum would only help if a script went crazy and started using excessive resources. But what about under ideal conditions, will setting these values lower increase server performance? And why is this?

Thanks in advance for your reply.

Posted on by fuerst (not verified).

You are right: This values are limits and will not lower the resource footprint of Apache/PHP processes under ideal conditions.

Posted on by Robert Douglass.

Thanks for the clarification. So I would modify my advice to not necessarily seek the lowest possible levels, but still to steadfastly protect sane levels and not cave in to arbitrarily raising these values ad infinitum to avoid out of memory or exceeded time limit errors that crop up during cron.

Robert Douglass
Senior Drupal Advisor, Acquia

Posted on by dean.kwasniak (not verified).

Hi Robert, I am getting an error when trying to run the script

The path for our server (opensuse) is -

/srv/www/vhosts/mallplace.com/httpdocs/scripts/drupal.sh -root /srv/www/vhosts/mallplace.com/httpdocs/ http://default/cron.php

The error id -

ERROR: index.php not found.

Posted on by CurtainDog (not verified).

@DK - There are two dashes before root

@all - Is there any reason not to use this technique? I suppose if you couldn't set up a cron job locally for some reason. I like the fact that you can use this to enable locking down of the cron.php and will recommend all our future deployments follow this pattern as well.

Posted on by soyKeymaster (not verified).

Hi Robert,

Great info, thanks. I'm glad I caught this BEFORE going live. I just thought I would add a little bit of info for RedHat Enterprise Linux (and CentOS) admins looking for this functionality.

I run Drupal 6 on a CentOS 5 box (with the latest 5.3 update packages) and the .ini file for the php CLI is /etc/php-cli.ini. This does not exist in the default installation so you'll need to create it as a copy of the /etc/php.ini file.

Posted on by Jasmine (not verified).

I googled this error and was directed here - great idea having the separate php.ini files.

Of course the earlier comment "This values are limits and will not lower the resource footprint of Apache/PHP processes under ideal conditions." means that this tip really just restricts the cron jobs from crashing your server.

Is it possible to have different settings depending on the apps? (ie - different php.ini's for each website)

Cheers,
Jasmine