Disabled wp-cron, set up system cron but still have missed schedule posts

Question

I have a caching plugin (WP Rocket) so I am aware of the issues with wp-cron and scheduled posts. So, I disabled wp-cron and then set up a system cron. Now, I noticed that when a post is scheduled it's not set to HH:MM:00 but has some number greater than 0 seconds. So, I set the system cron to run wp-cron at every 5 minutes and 35 minutes past the hour. And still I get missed schedule on posts. I know it runs as I have the output logged which shows a 200 return code plus I see my cache files with timestamps at 5 minutes and 35 minutes past the hour.

define('DISABLE_WP_CRON', true);

Cron entry (I x'd out my user name. I also have one for 35 minutes with output to wget35.log):

5   *   *   *   *   wget -o /home/xxxxx/logs/wget5.log https://www.jennystampsup.com/wp-cron.php?doing_wp_cron 2>/home/xxxxx/logs/wget5.err

Update

Using WP-Control I see that the check_and_publish_future_post event for the post remains as an event after wget runs. I can run it manually from WP-Control and the post_status went to publish. If I run wget twice it works. The first wget took one second. The second took 17 seconds, but after it ran the check_and_publish_future_post fired. I will create a script that runs wget several times with some sleep statements and that should do it.

Update 6/27

So, posts on my site are scheduled for 7:00:XX. So, I wrote a script that hits wp-cron.php 10 times, sleeping two seconds in between each hit, and had it kick off in my system cron at 7:01. And still publish_future_post did not fire. I looked at the WP Cron schedule prior to my script firing and there were 8 other cron events waiting to fire. They all fired. So, I went to Cloud9 and hit wp-cron.php from there. This caused the publish_future_post to fire. The only variables there are it is a different ip and time zone. Those should make no difference as far as I know. This is very puzzling.

Answer 1

With WP CLI I was able to avoid other plugins potentially interfering with publish_future post.

Below is a perl fragment. On my host webdir is $HOME/public_html and bindir is /usr/bin. Note the use of --due-now. Only those hooks currently waiting to be fired will run. Also note you either need to cd into webdir or add --path=path, where path is the path to the wordpress files (usually webdir).

# Post any scheduled posts ready to publish
my $cmd = "cd <webdir>; <bindir>/wp cron event run publish_future_post --due-now;
system($cmd);

# Run other cron events normally
$cmd = "cd <webdir>; <bindir>/php wp-cron.php";
system($cmd);

Then I set the script to run at 1,31 in my system cron as all posts either are scheduled for the top of the hour or the bottom of the hour.

Answer 2

Jetpack's site map cron event was just before my publish_future_post; which takes some time to run (In fact, I found with inserting some debug statements into wp-cron.php, that it never returns back to wp-cron.php). Using WP Crontol I moved it to after publish_future_post, and publish_future_post fired. I am guessing hitting wp-cron below the WP_CRON_LOCKOUT_TIMEOUT threshold of its default value of 60 secs was preventing publish_future_post from firing. When I hit wp-cron from Cloud 9 it was two minutes later, so publish_future_post was able to fire.

So, while moving control of WP Cron to the system cron is an accepted pattern, it seems it does not solve all the problems with WP Cron. I suppose I could add a sleep 60 in my script between each hit to overcome the issue of cron event that does not return control to wp-cron.php but such a script would be a long running script. And as noted above I cannot schedule a cron event in less than 30 minutes from a prior one as it would violate my hosts cron policy.

So, as long as a post is never scheduled for 7:30 am or pm, and the sitemap cron event never changes back to its original time I should be good.

I will contact Automatic and see what they say.