Revision as of 17:08, 10 August 2009

Cron Tasks

PhpBB has to carry out a number of periodic housekeeping tasks, the sort of thing that you would typically use cron for on a Linux system. These the following:

• Processing email queue. This executes a queue::process() includes/functions_messenger.php
• Garbage collecting on the cache. This executes a cache::tidy() and since cache extents acm, this actually executes acm::tidy in includes/acm/acm_file.php
• Garbage collecting on the database. This executes a tidy_database() in includes/functions_admin.php
• Garbage collecting on the search tables. This executes a tidy_search() in includes/search/fulltext_mysql.php (or fulltext_native.php if using the phpBB inbuilt text search engine).
• Garbage collecting on the sessions tables. This executes $user->session_gc() in includes/session.php.
• Garbage collecting on warnings. This executes tidy_warnings() in includes/functions_admin.php.

phpBB is designed to run on a basic shared web service, and therefore its implementation can't rely on a cron function being available. However, since some of these periodic housekeeping activities are processing intensive, it isn't practical to appended this processing as a synchronous step in a routine page transaction. phpBB therefore uses a trick that exploits the fact that most browsers implement a lazy image load policy during the page load. Hence the 'cron' processing is a dummy image generator which ultimately returns a one blank pixel image, but in reality this implements a callback from the browser to initiate the cleanup function. This doesn't noticeably the user experience during this delayed image load during the page load.

The way the cron hook is executed is that the footer template includes the hook:

 <!-- IF not S_IS_BOT -->{RUN_CRON_TASK}<!-- ENDIF -->

The page_footer setup function has an optional parameter $run_cron which defaults to true, and in fact is always called page_footer(), so this cron path is executed on every page generation. The code is (I've compressed its layout to save space):

 $cron_type = ;
 if ( time() - $config['queue_interval'] > $config['last_queue_run'] && 
      !defined('IN_ADMIN') && 
      file_exists($phpbb_root_path . 'cache/queue.' . $phpEx))             { // Process email queue
     $cron_type = 'queue';
 } else if (method_exists($cache, 'tidy') && 
            time() - $config['cache_gc'] > $config['cache_last_gc'])       { // Tidy the cache
     $cron_type = 'tidy_cache';
 } else if (time() - $config['warnings_gc'] > $config['warnings_last_gc']) {
     $cron_type = 'tidy_warnings';
 } else if (time() - $config['database_gc'] > $config['database_last_gc']) { // Tidy the database
     $cron_type = 'tidy_database';
 } else if (time() - $config['search_gc'] > $config['search_last_gc'])     { // Tidy the search
     $cron_type = 'tidy_search';
 } else if (time() - $config['session_gc'] > $config['session_last_gc'])   {
     $cron_type = 'tidy_sessions';
 }
 if ($cron_type) {
     $template->assign_var('RUN_CRON_TASK',
                           '<img src="' . append_sid($phpbb_root_path . 'cron.' . 
                                                     $phpEx,'cron_type=' . $cron_type) . 
                           '" width="1" height="1" alt="cron" />');
 }

Cron Bug

cron.php like all other phpBB transactions imports common.php to set up a common cote. However this include contains the following conditional which causes the cron.php task to fail in our shared code implementation, since this causes it to attempt to resolve the cache directory in /var/www/phpBB-common/cache which doesn't exist. What the logic for doing this, heaven knows, but my work-around is to reset $phpbb_root_path back after including this in the cron.php routine.

if (defined('IN_CRON'))
{
    $phpbb_root_path = dirname(__FILE__) . DIRECTORY_SEPARATOR;
}

I have put in this and now the cron tasks work properly, but for now I have also set the email_package_size parameter to zero. I will review this for tuning and optimisation later, but for now this works.