Cron clear boost cache inside the maximum life time period

I have a similar symptom as described in #7.
When an anonymous user (most of the time spam bot crawlers) are hitting node/add/blog, my whole static cache folder /cache/mydomain.com gets flushed.
This happens although a 401 is returned. So no actual content has been created yet !

Apparently triggered via a cron thread :

Having boost crawler enabled, as well as "Ignore a cache flush command if cron issued the request." and "Remove old cache files on cron."

Looking into the responsible piece of code of boost.module :

/**
 * Implements hook_flush_caches(). Deletes all static files.
 */
function boost_flush_caches() {
  // Remove all files from the cache
  global $_boost;

  // This may not have been invoked in hook_init because of the quick
  // check to avoid caching requests from the CLI
  $_boost = boost_transform_url();

  // The lock_may_be_available() checks to see if the flush was requested by
  // the core cron, since we may want to ignore it (boost_ignore_flush)
  if (isset($_boost['base_dir']) && (lock_may_be_available('cron') || variable_get('boost_ignore_flush', BOOST_IGNORE_FLUSH) == FALSE)) {
    $count = _boost_rmdir($_boost['base_dir'], TRUE);
    watchdog('boost', 'Flushed all files (%count) from static page cache.', array('%count' => $count), WATCHDOG_NOTICE);
  }
  return;
}

i am concluding that the first condition lock_may_be_available('cron') was met, since 'boost_ignore_flush' evaluates TRUE.

Having little understanding of what this lock function actually evaluates in relation to boost cached nodes.
Obviously it is checking the existance and expire value of 'cron' in the semaphore table.

function lock_may_be_available($name) {
  $lock = db_query('SELECT expire, value FROM {semaphore} WHERE name = :name', array(':name' => $name))->fetchAssoc();
  if (!$lock) {
    return TRUE;
  }
  $expire = (float) $lock['expire'];
  $now = microtime(TRUE);
  if ($now > $expire) {
    // We check two conditions to prevent a race condition where another
    // request acquired the lock and set a new expire time. We add a small
    // number to $expire to avoid errors with float to string conversion.
    return (bool) db_delete('semaphore')
      ->condition('name', $name)
      ->condition('value', $lock['value'])
      ->condition('expire', 0.0001 + $expire, '<=')
      ->execute();
  }
  return FALSE;
}

Sorry but this puzzles me, since i would expect some query instead evaluating the expiration of the cached nodes.
In my case the semaphore table is completely empty, returns true in the evaluation and flushes my static cache.
Wondering if the Ultimate cron installation might be conflicting with this evaluation, since boost might be expecting core cron settings and evalutions.

Reopend since no argumentation was added after now 2 similar symptoms, with boost crawler enabled.

Honestly, i believe the check should look like this :

  // The lock_may_be_available() checks to see if the flush was requested by
  // the core cron, since we may want to ignore it (boost_ignore_flush)
  if (isset($_boost['base_dir']) && (lock_may_be_available('cron') && variable_get('boost_ignore_flush', BOOST_IGNORE_FLUSH) == FALSE)) {

instead of :

  // The lock_may_be_available() checks to see if the flush was requested by
  // the core cron, since we may want to ignore it (boost_ignore_flush)
  if (isset($_boost['base_dir']) && (lock_may_be_available('cron') || variable_get('boost_ignore_flush', BOOST_IGNORE_FLUSH) == FALSE)) {

It reflects what the comment above it actually says it should do in combination with lock, not or lock.

Same problem here: All boost files are flushed, every time system corn is running.

The problem is that I don't know what lock_may_be_available('cron') and what it should deliver. In my case at least it delivers TRUE in every Case, no matter if cron is running or not. In my case, the semaphore table is completely empty, too.

So I doubt if lock_may_be_available('cron') checks to see if the flush was requested by the core cron like it is mentioned in the code.

I found out that there is a variable _cron_executing_job in the $GLOBALS telling if a cron is running. To be able to see, when boost cache is flushed without cron I added a message. So I came up with this code:

  // The $_cron_executing_job checks if the flush was requested by system_cron,
  // since we may want to ignore it (boost_ignore_flush)
  global $_cron_executing_job;
  $cron_is_running = FALSE;
  If ($_cron_executing_job == 'system_cron') {
    $cron_is_running = TRUE;
  }
  if (isset($_boost['base_dir']) && (!$cron_is_running || variable_get('boost_ignore_flush', BOOST_IGNORE_FLUSH) == FALSE)) {
    $count = _boost_rmdir($_boost['base_dir'], TRUE);
    watchdog('boost', 'Flushed all files (%count) from static page cache.', array('%count' => $count), WATCHDOG_NOTICE);
    if (!$cron_is_running) {
      drupal_set_message(t('Flushed all files ('.$count.') from static page cache.'), 'status');
    }

instead of:

  // The lock_may_be_available() checks to see if the flush was requested by
  // the core cron, since we may want to ignore it (boost_ignore_flush)
  if (isset($_boost['base_dir']) && (lock_may_be_available('cron') || variable_get('boost_ignore_flush', BOOST_IGNORE_FLUSH) == FALSE)) {
    $count = _boost_rmdir($_boost['base_dir'], TRUE);
    watchdog('boost', 'Flushed all files (%count) from static page cache.', array('%count' => $count), WATCHDOG_NOTICE);
  }

I just faced a similar problem and perhaps can provide some help for future visitors. I've had the same issue for months with one of the largest sites I manage. At first I thought it wasn't a big deal, until the site started to exhibit some performance issues. Administrators started to notice frequent slowdowns and after checking the watchdog I realized that the whole Boost cache was being flushed away every few minutes (sometimes, several thousand of perfectly valid entries were being deleted). I spent an entire morning trying to figure out why until I realized I was making an stupid mistake.

The site uses Ultimate cron to manage cron, which is invoked by a cron task every minute (as suggested). I was running the task like this:

* * * * * /usr/bin/drush cron -q

And that's the problem. What was happening, is that by invoking cron in that way every task in in the cron was being executed every time the cron was run, and caches were being flushed.

As per Ultimate cron's instructions, you should'nt invoke the cron in this way, but instead using something like this:

* * * * * /usr/bin/drush cron-run --uri=www.mysite.com --root=/var/www/public_html > /dev/null 2>&1

After making the change, everything worked as expected. I'll keep an eye on the watchdog for a couple of days, but after 4 or 5 hours things look great.

Quick follow-up. Today, I noticed that the system cron task (which runs every 12 hours in the site) still flushed away the whole Boost cache. Still an improvement from before, but definitively not ideal. As it turns out, it's a know issue with Ultimate cron and the lock_may_be_available() function (as suggested above), but it's been fixed:

https://www.drupal.org/project/boost/issues/1829832

After applying the patch in that thread the issue has been completely solved.