[Plugin: WP Super Cache] mutex locked?

See the Troubleshooting section of the readme.txt. Point 13. Does that help?

You could also try upgrading by copying the files from https://svn.wp-plugins.org/wp-super-cache/trunk/ over your current install.
Then edit wp-content/wp-cache-config.php and add “$wp_cache_mutex_disabled = 1;”

That *might* cause a lot more file operations to happen on your server though, especially if you have a very busy site. It disabled file locking so things don’t happen one at a time.

I uncommented “$use_flock = true” but I am still receiving the same error.

As far as “or set $sem_id to a different value”, I have not tried that because I don’t know what to set it to. What might that value be? just some random digits?

Before you ask… mutex.lock is 644

Thanks in advance.

Either delete that mutex.lock manually, or upgrade your files. I’d say you’ll have better luck with upgrading!

Yes, $sem_id can be any value you like. It doesn’t really matter what.

OK so, I tried everything

uncommented “$use_flock = true”
edited $sem_id
manually deleted mutex.lock

but the problem still exists. I will try your next release as it seems that you are addressing the issue. That being said, what server configuration issue do you think is causing this problem?

I would rather address the underlying issue then hack your plugin! Thanks again for your time.

The underlying problem could be an underpowered server and a very busy site. The changes I made to the file locking isn’t a hack.

No other caching plugin uses similar file locking which is fine for most people, but it obviously causes problems on some servers. Why not update? You’ll be helping me solve this.

“Why not update? You’ll be helping me solve this.”

Because I am a chicken! Although I do appreciate your work and i will try to update tomorrow.

That being said, I am now seeing that the regular expired cache seems to be clearing out. Why would those files clear but not the super cache? is there some minimum number of files that have to be in place before it will delete them?

Donncha,

I auto upgraded, set up the debug email, and I was receiving an email every minute saying that the cron job failed even though the expire time was set to 3600. This looks like some kind of bug, I don’t think it should just continue to run if it failed.

All of that being said, after I checked the new option that deals with locking things seem to be cleaning up as they should now and I am not receiving any debug emails.

I hope this helps.

I’m having the same problem, but I can offer a little additional info.

First, you get an E-Mail every minute because if the cron fails it schedules another for one minute later to try to recover. If the problem was a usage spike or something, this would be really handy.

I had to check the box in settings that says “Disable file locking. If you experience problems with mutex or file locks this may help but may cause increased server load.” The *REALLY WEIRD* thing is that I added do_action('wp_cache_gc'); to a page template and it ran perfectly, cleaning up all my expired files, even without that box checked. However, adding wp_schedule_single_event(time() + 10 , ‘wp_cache_gc’) to that same template does NOT help the problem (still needs that box checked).

aaroncampbell – sounds like your wp_cron isn’t firing. Do scheduled posts work?

Aaron – Update to the development version (it’ll update in the next 15 mins) or grab the plugin files from https://svn.wp-plugins.org/wp-super-cache/trunk

I added a new config option $wp_cache_shutdown_gc to the config file. Set it to 1 to use the shutdown part of the PHP process to delete expired files. It’ll mean that the occasional visitor will see a slow loading page but it might work better than the cron job.