search

wpsharks / comet-cache

An advanced WordPress® caching plugin inspired by simplicity.
https://cometcache.com
GNU General Public License v3.0
76 stars 17 forks source link

cron_zencache_cleanup never executing! #653

Open xberg opened 8 years ago

xberg commented 8 years ago

Hi Using Pro version 160103. The _cron_zencache_cleanup never executes. I use Crontrol to monitor the wp_cron and there's very strange behavior: The "next run" time keeps changing!!! I have it set to run every 3 hours, but the next run time is always in just 1 minute time! When I refresh the crontrol page I see your CRON is still schedule to run in a minute. and it NEVER NEVER runs. So this just fills my cache and I have several times a day to manually delete the cache! Same bahavior with _cron_zencache_auto_cache but I don't use this.

I tried deleting and reinstalling: same problem.

And you CRONs are the ONLY ones I cannot delete or edit with crontrol. It's like your system is continusouly deleting and recreating new ones!

Please help me fix this ASAP.

raamdev commented 7 years ago

@renzms Thanks for the testing!

I just did another review of this entire GitHub issue and the associated source code and I'm totally out of ideas. @xberg was unable to reproduce the issue in a cloned version of the site, but at least 3 other people have reported this issue, even after we implemented an attempted fix. The issue occurs in both Multisite and Single-Site installations.

The issue appeared to be related to one of (or both of) these two conditionals:

            || $this->options['crons_setup_on_wp_with_schedules'] !== sha1(serialize(wp_get_schedules()))
            || !wp_next_scheduled('_cron_'.GLOBAL_NS.'_cleanup')

I'm completely fresh out of ideas. :-) It would be nice to have access to a site that is experiencing this issue.

@jaswsinc Any ideas?

jaswrks commented 7 years ago

From our research in this issue, we have learned that WordPress schedules and then re-schedules events, which can lead to a loss of the custom timeframe that we add to WordPress via filters. That's a bug in core, which can result in a number of CRON events becoming corrupt.

I see two problems in the existing release:

I see two possible avenues from here:

  1. Work to correct this in core and submit a patch.
  2. Or, avoid WP Cron altogether and deal with this on our own. The objective here is just to run the ACE every few minutes automatically. If we remove WP Cron from the picture, that's a pretty simple and straightforward task that is easily accomplished in PHP without any library.
xberg commented 7 years ago

Yes: this is very very strange behavior: on mysite.com I have the issue each time I update the plugin as this removes my commented-out line. However on the clone which is hosted on the same server with exactly (*) the same setup / plugins but just a different URL : dev.mysite.com it works perfectly. I just did this 2 days ago: a new clone, updated Comet Cache from V 161227 to the current version and it worked fine out of the box.

I'm sorry as I know none of this is helpful for your debugging. I cannot give you access to my production platform due to customer confidentiality. However I am sure I am just the top of the iceberg: very few people care or know about 1. what's happening in their wp-cron and 2. the size of their cache folder. I'm a sort of alignment of stars in that I use limited memory to cache comet cache and I have wp-crontrol installed. Perhaps having a window in comet cache showing cron execution will bring a lot more tickets and data :)

(*) only difference is that the dev platform runs an additional plugin "stop email" to avoid sending out emails to users. And in DEV we define wp_home and wp_siteurl directly in wp-config.php... Oh: and DEV does NOT use memory to store comet cache folder

raamdev commented 7 years ago

@jaswsinc writes...

This bug that exists in WordPress core is potentially the underlying cause.

That reminded me of this todo I had in my task list from a long time ago that I never got around to, related to bugging WP Cron. It was filed in my task manager as unrelated to this issue, but now that you mentioned buggy WP Cron, I was reminded of it. There's likely more background related to this issue here: https://github.com/websharks/comet-cache/issues/613#issuecomment-162317215

ogessel commented 7 years ago

I'm having the same issues, as Raam already knows. https://forums.wpsharks.com/t/cron-jobs-seem-to-be-running-always/2636

And I'm happy to give you admin access to my set up if you want to look around.

ogessel commented 7 years ago

And I can confirm that solution proposed by xberg of February 22nd does do the trick.

Since I'm not a developer, I'm not sure what it now is doing or not doing anymore, but after having commented out that line the Cron jobs seem to perform like the other ones. In English: normally.

Of course I still hope that about a bug fix will be available shortly. Greets, Olaf

xberg commented 7 years ago

@ogessel Don't hold your breath for the fix: I have to do my manual fix with each update for the last 1.5 years. But indeed if you are willing to give the devs an admin access they might finally have a platform in which they can reproduce the bug.

raamdev commented 7 years ago

Until this issue can be reproduced in a testing environment, or until we can clearly identify what's causing the problem, it's not possible to put out a fix. The code that @xberg mentioned commenting out is designed to to make Comet Cache compatible with custom WP Cron schedules and to ensure that the Comet Cache WP Cron events are scheduled.

The following is an explanation of the purpose of the two statements that @xberg is commenting out.

$this->options['crons_setup_on_wp_with_schedules'] !== sha1(serialize(wp_get_schedules()))

This line checks if the WP Cron Schedules have changed by comparing a stored SHA1 hash in the database ($this->options['crons_setup_on_wp_with_schedules']) with the SHA1 hash of the current WP Cron Schedules (sha1(serialize(wp_get_schedules()))). If the hashes are different, that means that the WP Cron Schedules have been modified in some way and Comet Cache needs to go through the process of setting up its WP Cron events again to ensure that they are scheduled properly. Any WordPress site owner can modify the default WP Cron schedules. Other WordPress plugins can also modify WP Cron Schedules. In either event, Comet Cache needs to ensure that its own event is scheduled properly, because if somebody modifies a WP Cron Schedule that Comet Cache is using, Comet Cache needs to reschedule the even to ensure that the modified schedule is used.

!wp_next_scheduled('cron'.GLOBAL_NS.'_cleanup')

This line simply checks to see if the Comet Cache cleanup event has been scheduled. If it has not been scheduled, then Comet Cache needs to run through the setup routine to make sure that it's scheduled. Once it has been scheduled, this line should evaluate to false. However, as @lkraav noted in an earlier comment, he found that line was always evaluating to true, which was causing an endless loop for him. That makes little sense to me because it would indicate that Comet Cache is never able to properly schedule the cleanup event, or the wp_next_scheduled() WordPress function is returning an incorrect value.

Again, I have not been able to consistently reproduce this issue at all on my end. It seems to be somehow related to specific hosting environments, but unless I can get full access (admin, FTP, and database) to a server where this is occurring, it's simply not possible for me to troubleshoot the issue.