Let's say I disabled "DISABLE_WP_CRON" in wp-config.php
Is it OK to run wp-cron.php twice overlapping?
I've noticed sometimes wp-cron.php needs several minutes. I'd give it a full hour but the blogger I work with does a lot of scheduling through the day, she's very busy.
Like say I have it running every 10 mins with a real crontab
*/10 * * * etc.
And it needs a full 15 minutes to do its business. 15 minutes is just a random example here. There doesn't seem to be any rhyme or reason for how long it takes.
Can two "instances" of wp-cron.php safely run together? Does the oldest instance die and the new one takes over? From what I can tell from my bash script that runs wp-cron.php, the first instance fails when the new instance starts.
Example: cron kicks off wp-cron.php at 11:01pm.
php /home/www-data/example.com/wp-cron.php && echo "wp-cron.php done" | mailx [email protected]
11:21pm wp-cron.php starts again (*/20) and I still haven't got my "done" email. But this time I get the "done" email 17 seconds after the subsequent wp-cron.php ran.
(Not sure if wp-cron.php failed on its own or if wp-cron.php killed itself after running 2x.)
So I'm wondering: Is data lost from the first instance? The abrupt failure of a process that was running for 10 minutes seems "bad" to me. At this point, I'm tempted to stop using crontab and go back to the wp-config default behavior because this is way more trouble than I bargained for.
This doesn't sound very reassuring either: How is WP Cron Locking implemented?
What if the "transient" is not deleted before the first process dies? Are the unfinished tasks forever unfinished then? And what is a transient? I assume it's some kind of flag.
I'm having major problems with this today. Server got slow, triggered some timeouts which I assume caused wp-cron.php to fail, resulted in double postings, scheduled posts not posting, what a nightmare!
Update: Attempting to call wp-cron.php from the operating system with crontab was a huge waste of time for me and the client. On my end, wp-cron.php seemed to execute fine, used memory and CPU time for various durations, but the scheduled posts never posted according to my client. It would be nice if there was a "verbose" mode to indicate what it's actually doing. I ran out of time to investigate this and went down another route. I just worked on improving the speed of the server which somehow fixed the problem. (My guess is, some timeout was reached because the server was overloaded.) I was hoping I could just get a crontab working quickly before I worked on upgrading the server. But the more I looked at wp-cron.php, the more I distrusted it. Failed scheduling, double posts, conflicting advice how it should be executed. So that's why I came here. I have a similar script for one of my own websites that runs hourly--it's not designed to overlap itself but it's fairly safe if it does, within reasonable parameters. Then again, I know what's reasonable to me. I don't know what's reasonable to the author of wp-cron.php.
So this was a distraction and a dead-end for me. I changed wp-config.php back to the default (deleted DISABLE_WP_CRON) and let WordPress deal with wp-cron.php. Now with a faster server, WordPress schedules posts again just fine. Always safer to stick to defaults.
More details of the story here: http://tomakefast.com/when-wp-cron-php-sceduling-fails-3003/
wp_cron
is a very simple tool. A job has a time. When a user visits a page the time is checked and if it has elapsed the job runs. That is the default mechanism for runningwp_cron
. You can't schedule a job with pinpoint precision-- that is a limitation imposed by the way the PHP itself works. I don't know what is open-ended about that. People run jobs at different intervals because they want different intervals. Because you can't schedule with pinpoint precision some people attempt to leverage other software, like cron, to prod the server on a regular basis.