Справка по отладке "запуск cron превысил ограничение по времени"

Я написал пользовательский модуль (для Drupal 7 и PHP 5.3), который использует hook_nodeapi() и не разрешает доступ к определенному типу узла, а просто перенаправляет (с помощью drupal_goto()) на главную страницу списка с предупреждающим сообщением.

Однако у меня есть подозрение, что модуль Boost (с включенным "Не кэшировать страницы с сообщениями") захлебывается при запуске cron, когда доходит до этих типов контента, и продолжает перенаправляться (я не знаю, как точно работает Boost, но я предполагаю, что он кэширует несколько страницы на запусках cron?).

Причина моих подозрений и реальная проблема в том, что cron после определенного количества запусков начинает завершаться сбоем с сообщением об ошибке "Запуск Cron превысил ограничение по времени и был прерван"., и сразу после этого сообщения на Watchdog появляется следующее сообщение: "На этой странице есть сообщения Drupal, предотвращающие кэширование boost".

Я поместил отладочный фрагмент кода на module.inc (взломанное ядро, как было предложено здесь), чтобы увидеть, какой модуль был ответственен за этот сбой, и каждый раз, когда происходит сбой cron, последним модулем, который обращался к Cron, кажется, является модуль "Поиск" (основной):

Повышение 22/02/2012 - 9:00 По этому поводу есть сообщения Drupal... Анонимный
cron 22/02/2012 - 9:00 Запуск Cron превысил лимит времени и был прерван. Анонимный
cron 22/02/2012 - 9:00 утра нажмите поисковый анонимный cron
cron 22/02/2012 - 9:00 утра анонимный доступ к узлу cron
крон 22/02/2012 - 9:00 утра анонимный хит фильтра cron
cron 22/02/2012 - 9:00 утра хит dblog cron Анонимный
повышение 22/02/2012 - 9:00 утра Просроченные устаревшие файлы из статического кэша страниц. Анонимный
cron 22/02/2012 - 9:00 утра хит повышения анонимного cron

С тех пор я сократил количество страниц для индексации, но это не помогло. Cron, который запускается после поискового cron, является "системным" cron, но я понятия не имею, что именно делает этот cron.

В раздражает то, что вы заходите на страницу cron, набирая текст в браузере http://address/cron.php или через командную строку wget http://address/cron.php он работает нормально. Но из заданий cron системы он в конечном итоге сталкивается с этой проблемой после нескольких успешных запусков cron.

Я был бы признателен за любую помощь в решении этой проблемы или за толчок в правильном направлении. Спасибо.

/**
 * Implements hook_nodeapi().
 */
function rhask_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  switch ($op) {
    case 'view':
      if($node->type == 'question' && arg(0) == 'node' && !user_access('administer questions')){
        drupal_set_message('Access Denied - You cannot access this content directly. Please use this page.', 'warning');
        drupal_goto('ask');
      }
      break;
  }
}

Думаю, я мог бы сделать перенаправление без установки какого-либо сообщения. Это может решить проблему, если действительно Boost вызывая проблемы с cron, я отредактирую это сообщение, когда получу какой-либо результат.

Редактировать: Cron успешно запускается каждые 30 минут со вчерашнего дня, и изменения, которые я внес в настройки модуля XMLSitemap, похоже, сделали свое дело. Я буду продолжать следить за этим сайтом еще несколько дней.

Правка2: Крон все еще терпит неудачу. Я удалил drupal_set_message, поэтому теперь он перенаправляет без установки каких-либо сообщений. Однако это не мешает cron неудача. Boost больше не жалуется и просто регистрирует "Устаревшие файлы с истекшим сроком действия из статического кэша страниц". Я не знаю, как действовать дальше, чтобы изолировать эту проблему.