System Administrator's Guide/Cron Job

Some tasks in Mahara need to be run at scheduled times. This is achieved by use of a cron job. You set up a job to visit a Mahara script every minute, and it takes care of the rest.

Some of the jobs it does include:

• Updating syndicated RSS feeds
• Mailing out forum post updates and other batch notifications
• Cleaning up old files to save space

How to set up the cron job

The cron script is lib/cron.php. You need to set  up a job to visit this script every minute - either through the web by visiting http://your-mahara-site.org/lib/cron.php, or by the command line, calling php /path/to/mahara/htdocs/lib/cron.php. Both ways have their advantages and disadvantages.

Calling cron.php via the web

This is a simple way to get cron going. In your crontab, you need only put a line like this:

* * * * * curl http://your-mahara-site.org/lib/cron.php >> /dev/null 2>&1

It reads, "every minute, use 'curl' to hit the cron.php script".

This way is very simple.

Note: Calling cron.php via the web produces no output to the browser. Output is in the web server error logs, which you don't normally want, but it's better than exposing potentially revealing output to the public.

Another even more simpler way is using webcron:

By registering on webcron service site likes https://www.easycron.com, you can add a cron job with URL "http://your-mahara-site.org/lib/cron.php". Your URL will then be called periodically according to your setting, so that your cron.php will get executed.

Calling cron.php via the command line

This way is slightly more difficult, but allows you to log the cron output separately. The trick is, you have to run the cron job as the web server user, so it has all the rights it needs. You can either do this by installing the cron job into the web server user's crontab, or by installing it into root's crontab with the user field set to the web server user:

In the web server user's crontab:

* * * * * php /path/to/mahara/htdocs/lib/cron.php >> /path/to/mahara/cron.log 2>&1

Or, in root's crontab (substitute www-data with the web server user):

* * * * * www-data php /path/to/mahara/htdocs/lib/cron.php >> /path/to/mahara/cron.log 2>&1
  

This way has a couple of caveats:

• Make sure that the log file can be written to by the web server user. On debian, you could make a directory /var/log/mahara-cron, and chown that to www-data. Then you could make the logfile path /var/log/mahara-cron/cron.log.
• The php.ini used by command line PHP is not the same as the one used by Apache PHP. E.g., in Debian, Apache uses /etc/php5/apache2/php.ini, while the command line PHP uses /etc/php5/cli/php.ini. So either you make sure both of them are the same, or it may make sense to use the -c flag with your PHP call, like so: * * * * * php -c /etc/php5/apache2/php.ini /path/to/mahara/htdocs/lib/cron.php >> /path/to/mahara/cron.log 2>&1
• Under some distributions (e.g. Debian), the manner in which extensions are loaded can cause php to Segmentation Fault. This appears to be caused by the php curl module being loaded before the postgres module. You can fix this by moving curl.ini to something lexically later (e.g. Z99_curl.ini).

Sample Output

(RedHat crontab)

*/30 * * * * php /path/to/mahara/htdocs/lib/cron.php >> /path/to/logfiles/mahara.log 2>&1
 
 [DBG] b4 (lib/cron.php:45) ---------- cron running Wed, 03 Oct 2012 12:00:02 -0700 ----------
 [DBG] b4 (lib/cron.php:90) Running PluginBlocktypeExternalfeed::refresh_feeds
 [DBG] b4 (lib/cron.php:90) Running PluginInteractionForum::interaction_forum_new_post
 [DBG] b4 (lib/cron.php:146) Running core cron rebuild_artefact_parent_cache_dirty
 [DBG] b4 (lib/cron.php:146) Running core cron activity_process_queue
 [DBG] b4 (lib/cron.php:146) Running core cron import_process_queue
 [DBG] b4 (lib/cron.php:168) ---------- cron finished Wed, 03 Oct 2012 12:00:29 -0700 ----------