[Plugin: WP Super Cache] Expired pages not being removed

Is it all expired files aren’t deleted or only some?

The first place to look would be the wp_cache_phase2_clean_expired() function in wp-cache-phase2.php – that does the cleanup. Use error_log() to debug it.

As far as I can tell, no expired files are being deleted automatically, at all. I’ll check the function you listed and see what it’s doing and if it’s actually even being called.

Very strange, as soon as I added some debugging code, it starts deleting files – at least some of the time. Most of the time, though, wp_cache_phase2_clean_expired() is doing absolutely nothing. It seems that every so often, $mutex_filename is unset, as I occasionally see this error:

wp_cache_mutex_init failed:
Array
(
    [type] => 2
    [message] => fopen(/var/www/bad-behavior.ioerror.us/html/wordpress/wp-content/cache/) [<a href='function.fopen'>function.fopen</a>]: failed to open stream: Is a directory
    [file] => /var/www/bad-behavior.ioerror.us/html/wordpress/wp-content/plugins/wp-super-cache/wp-cache-phase2.php
    [line] => 156
)

Not entirely sure why that’s happening, as it seems it should be set.

Ah, I think I have the problem, let’s see if you agree. In wp-cache-phase1.php there is the following code:

if(defined('DOING_CRON')) {
        require_once( WPCACHEHOME . 'wp-cache-phase2.php');
        return true;
}

$mutex_filename = 'wp_cache_mutex.lock';

So if we’re called from cron, $mutex_filename never gets set! I think instead this should be:

$mutex_filename = 'wp_cache_mutex.lock';

if(defined('DOING_CRON')) {
        require_once( WPCACHEHOME . 'wp-cache-phase2.php');
        return true;
}

Making this change locally appears to have resolved the problem. The mutex is acquired every time, and the directories are being traversed, and old files are being deleted.

Good catch! The mutex caching is disabled by default though so hopefully this won’t be something that has affected many people.

I’ve moved the cron code down so that the mutex file is set, as well as other variables are set too.

Thank you for debugging it!

It’s disabled by default but – as I understand the code – still ends up getting used if semaphores aren’t available for some reason (as on my server). So there are probably a lot of people in this situation that don’t even know it.

No, in the last few months there’s an option on the admin page for “coarse locking” that is disabled. No file locking at all now as the plugin writes to temporary files (takes a while) before renaming to the final cache filename (atomic, or so I’ve heard).

The writers entry and exit functions do nothing when coarse locking is disabled. Probably would affect users who upgrade and don’t look at the admin page however. They may have had it enabled since the old days.