After working with some multisite customers, we have come across a serious bug in the implementation of the current cron and best practices for Drupal implementations.

A typical cron implementation in crontab looks like this:

00 * * * * /usr/bin/wget -O - -q http://foo.com/cron.php

In a multisite installation, you do:

00 * * * * /usr/bin/wget -O - -q http://foo.com/cron.php 00 * * * * /usr/bin/wget -O - -q http://bar.com/cron.php

The problem is that the cron can at time be expensive to run, especially on sites that require a lot of indexing or that have not had the cron run in a while. Once of the solutions that’s been posted on the drupal dev lists was to change the line to:

00 * * * * /usr/bin/nice -n 10 /usr/bin/wget -O - -q http://askaninja.com/cron.php

nice is a command that runs a program with modified scheduling priority, essentially telling the linux kernel at what level to run the thing at (so that it doesn’t consume the machine resources insanely). The problem with this command is that it nices the wget process, NOT the apache process that’s doing the cron, so in fact it does nothing (well, it MIGHT process wget a little slower, but who cares?).

So, one solution is to run php from the command line, and this solves the problem in as much as Drupal is running as a single instance.

Instead of using the command line to run a wget, you actually just use a command line version of php, for example:

00 * * * * /usr/bin/php -q /file/path/to/drupal/install/cron.php

This works great! BUT! It will execute only for localhost, which means all your virtual hosts are left in the lurch (and lurching is bad for everyone). So the delimma is how to inject the vhost configuration into the command-line for Drupal multisite so that cron.php will pick it up. And right now, we have no working solution for it.

This is a serious issue that the Drupal community should address, as currently it can cause system stability issues in multisite installations. There may be an easy fix, but we’ll update if we find it.