Jobs queue not working

That actually sounds like a problem with the scheduled jobs not executing (any more) Oksana. Can you check the info in this FAQ entry?

frank

Hello Frank,

Thanks for your reply!

I’ve contacted the hosting and they moved the cron job execution to system cron. After that, I deactivate/activated plugin again and saved again with a setting to “Inline and defer critical CSS”. The plugin saved one rule (for the front page) almost immediately. And the new requests appeared in the Critical.css dashboard and some jobs moved to “P” status. But after some time everything stopped again: no new rules were saved (only the home page) and some jobs in “P” and a lot of in “N”.

Thanks

* so timing wise; how long ago did you hoster change to system cron & how long has the site been running that way?
* did you indeed check WP Crontrol output as per that FAQ entry? do you see the ao_ccss_queue job being listed? what’s the next execution time?
* if the problem persists (let’s say you’re not seeing any new rules at 20h00 UTC tonight), can you enable debug logging in the advanced settings + provide me your site’s URL?

frank

Hello Frank,

1) It’s been running on system cron for almost 24 hours now. After this change, some of the cron events from the Crontrol were properly rescheduled for the future, but some (including ao_ccss_queue) are still in the past.
2) ao_ccss_queue is listed here with the past timestamp. When I activate/deactivate the plugin, the cron event timestamp changes to the time of activation and doesn’t reschedule again.
3) I’ve enabled the debug log and this is the link: https://www.mein-adventskalender.de

I’m not sure if that’s related, but I’ve noticed that the plugin stopped working after Swift Performance caching plugin was installed. It was deleted after several days and isn’t on the website for several weeks now, but maybe you already had reports connected with it.

Thanks!

Hello, @optimizingmatters,

Did you get a chance to review the log?

Thanks,
Oksana

not yet, on my to-do list for tomorrow ??

@optimizingmatters , thank you! I will be connected if anything needed from my side at okskozub(at)gmail(dot)com.

Hey Oksana;
Had a look at the queue debug log and;
* you have a huge amount of the following lines in the queuelog-file (over 27.000 entries!);

[DD] Job queuing is not available for WordPress’s logged in users, feeds, error pages, ajax calls, to criticalcss.com itself or when a valid API key is not found

does this mean you have a lot of logged on users accessing the site?

* but more importantly; the cron job is simply never triggered, there is no “Queue control started” in the queueulog file. Based on this and on the fact that you wrote that “some [cron events] (including ao_ccss_queue) are still in the past” leads me to conclude there still is a problem with the (system) cron, although I can’t really tell what that problem would be I’m afraid :-/

frank

Hello Frank,

About the long long file, I think the main contributor from the reasons you quoted is the ajax. The website uses the Ajax calls a lot to communicate with external API.

but more importantly; the cron job is simply never triggered, there is no “Queue control started” in the queueulog file.

That is strange, after deactivating/activating a plugin, the queue is filling with “N” jobs instantly and some of them are moved to “P”, but the only rule saved from the process is for the home page. From the critical.css dashboard, only one API request is made. Screenshot If the cron was an issue, why the queue seems to work first several minutes? I’m totally confused. Also, I don’t understand why it stopped working after it worked correctly ??

Is there anything I can do to help with debugging?

Thanks,
Oksana

@optimizingmatters , could it be interfering with Varnish caching? I’ve noticed that after I’ve deleted the Proxy Cache plugin, queue worked for several minutes again.

If the cron was an issue, why the queue seems to work first several minutes?

the first job becoming P is not a result of the asynchronous queue processing, but of the synchronous API key check upon activation. so the queue is not running, even not for the first minutes.

Also, I don’t understand why it stopped working after it worked correctly

that, indeed, is the big question.

I’ve noticed that after I’ve deleted the Proxy Cache plugin, queue worked for several minutes again.

do you mean that extra P jobs are appearing and/ or that new rules are created from processed jobs?

@optimizingmatters ,

do you mean that extra P jobs are appearing and/ or that new rules are created from processed jobs?

I’ve noticed the new request on critical.css dashboard. But it could be as you said executed apon activation.

I’ve also tried to add the wp-cron.php to Cloudflare page rules to bypass the cache. But it didn’t help. Also, from critical.css dashboard, I’ve received the 503 error message: Screenshot

OK, now the screenshot is _very_ interesting as;
* it confirms some queue processing is happening (the queuelog seems not to exist, guess you disabled debug logging, so can’t confirm)
* the 503 indicates the criticalcss.com service cannot reach your site. could be some “protection” from cloudflare to stop unknown bots?

@optimizingmatters ,

I’ve enabled the log back. And I’ve removed the proxy settings from Cloudflare and only left the bare DNS. Is there an IP that can be whitelisted by Cloudflare or Wordfence for critical.css?

• This reply was modified 5 years, 5 months ago by oksanaromaniv.

If possible it’s better to whitelist criticalcss.com via user-agent instead of IP, as there will be new IPs added in the future.

User agent:
https://criticalcss.com

If you cannot make use of the User-Agent, the most likely IPs you will be hit by are:
138.68.175.225
159.65.84.28