Regular calls to Drupal cron.php scripts on a server with a number of Drupal sites

Calling the cron.php of a Drupal site is fairly easy. You just have to put something similiar into your server's /etc/crontab:
0 * * * * www-data test -x /usr/bin/wget && /usr/bin/wget --bind-address 127.0.0.1 -t 1 "http://example.com/cron.php"
Or you can place this wget call in a file in /etc/cron.hourly.

However on a server with quite some Drupal sites (and possibly a number of virtualhosts) the maintenance of these cron.php calls in your crontab becomes very annoying (and it is prone to errors). On a busy development server Drupal sites come and go every day. So why not do these calls automatically? The attached script does just that. Smile

The script is self-documented, just read the comments. To help Google searches find this page, I'll copy the script's leading comments here ...

This script is meant to find all Drupal directories in a structured subtree and call the cron.php script in each Drupal installation.
By default the script assumes that the directories inside the {wwwroot} directory wear the name (actually the FQDN) of the virtualhosts that they represent, and that inside these directories there's a {virtual_subdir} directory which is the documentroot of the virtualhost. The Drupal installations should reside in a child directory of these {virtual_subdir} directories.

Eg.
  • /var/www/domain1.com/www/cron.php
  • /var/www/domain2.com/www/subdir1/cron.php
  • /var/www/domain2.com/www/subdir2/cron.php
  • /var/www/www.domain3.com/www/cron.php
If you do not use any subdirectories for www content in your virtualhost directories, then set the {virtual_subdir} to an empty string.
This would assume the following directory layout:
  • /var/www/domain1.com/cron.php
  • /var/www/domain2.com/subdir1/cron.php
  • /var/www/domain2.com/subdir2/cron.php
  • /var/www/www.domain3.com/cron.php
If you do not use virtualhosts at all (eg. default Apache installations come usually with a DocumentRoot of /var/www), then set {use_virtual_dirs} to "no".
In this case your directory layout would probably look like this:
  • /var/www/subdir1/cron.php
  • /var/www/subdir2/subdir21/cron.php
  • /var/www/subdir2/subdir22/cron.php
You should execute this script from some system-wide cron mechnism periodically, eg. you could put this script into /etc/cron.hourly or call it from /etc/crontab or some user's crontab. The script produces output only in case of an error, thus if your system is set up correctly, the system cron should send you an email containing a detailed report for all erroneous cron.php calls.


P.S.: don't forget to limit access to your cron.php scripts to the localhost. This way only your scheduled wget calls will be able access the Drupal cron scripts.
Eg. append this to the .htaccess in your Drupal directory:
<Files cron.php>
  Order deny,allow
  Deny from all
  Allow from 127.0.0.1
</Files>

AttachmentSize
drupal_cron-1.0.0.sh3.13 KB
drupal_cron-1.0.1.sh3.4 KB
drupal_cron-1.0.2.sh3.43 KB

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Drupal cron caller v1.0.1

Added:
  • Process subdir only if the directory's name can can be resolved as hostname by the host command.
  • Call the cron script if the script's directory contains a file named .run_cron too. Previously cron was called only if the subdir seemed to hold a Drupal installation (ie. the files update.php and index.php, and the directory sites existed). Now you can use this Drupal caller script for custom PHP projects too, you just have to name your cron-like script cron.php and place a .run_cron file besides it.

Drupal cron caller v1.0.2

Fixed:
  • Improved POSIX shell compatibility (the function definition started with the function keyword whereas POSIX sh does not require or allow this; and there was a == operator used for string comparison, but POSIX sh uses a single = for that).
    (The bug appeared once I upgraded our Debian Lenny servers to Squeeze which replaced the old sh shell with dash ... which appears to be more strict about POSIX compliance.)