Known issue. See here: http://trac.wordpress.org/ticket/3713
The most obvious cause of the problem is a missing wp-cron.php file. WordPress 2.1 includes a wp-cron.php file in the root directory of the blog. This file must be present or you get this error.
A fix has been made to prevent this issue in future versions, but for now, the simplest fix is to have the wp-cron.php file there.
To really fix it, edit the wp-includes/cron.php file. Find the wp_cron() function and add these lines to the beginning of it:
function wp_cron() {
// Prevent infinite loops caused by lack of wp-cron.php
if ( strpos($_SERVER['REQUEST_URI'], '/wp-cron.php') !== false )
return;
...
Thanks Otto42!
By the way, this has nothing to do with Bad Behavior?
Nope. Totally unrelated.
Might want to make sure you have the latest version of BB though, just in case. I think some older versions do have issues, though none like this.
I’m having the same kind of server load/server utilization pattern, though I have the wp-cron.php file in my root, and my wp-includes/cron.php file already has the mentioned fix.
Here’s what my ISP just told me:
It seems that there is a local script that executes a connection to a internal resources each 2 seconds:
67.15.211.3 – – [28/Feb/2007:11:13:35 -0600] “GET /blog/wp-cron.php?check=131accfed8363d4c40f4b38b43f9d129 HTTP/1.0” 403 – “-” “-“
67.15.211.3 – – [28/Feb/2007:11:13:37 -0600] “GET /blog/wp-cron.php?check=131accfed8363d4c40f4b38b43f9d129 HTTP/1.0” 403 – “-” “-“
67.15.211.3 – – [28/Feb/2007:11:13:44 -0600] “GET /blog/wp-cron.php?check=131accfed8363d4c40f4b38b43f9d129 HTTP/1.0” 403 – “-” “-“
67.15.211.3 – – [28/Feb/2007:11:14:06 -0600] “GET /blog/wp-cron.php?check=131accfed8363d4c40f4b38b43f9d129 HTTP/1.0” 403 – “-” “-“
67.15.211.3 – – [28/Feb/2007:11:14:13 -0600] “GET /blog/wp-cron.php?check=131accfed8363d4c40f4b38b43f9d129 HTTP/1.0” 403 – “-” “-“
Any ideas?
Rich
[sig moderated]
Same effect here. wp-cron.php is in root and available by HTTP. I have applied that fix to wp-includes/cron.php which – obviously – does not help.
I’m running a dedicated server and would like to know some howto for setting up separate system cron job … is there some doc available. Yeah, send me RTFM-flames as well 😉 …
Good luck, Soletan, either nobody knows what’s going on with this, nobody cares, or it has no impact — because this issue has been raised elsewhere before and nobody seems to have answers.
Weird.
Rich.
Yes, it would seem that the wp-cron.php implementation is fundamentally evil since it spawns ever increasing server requests which seem to stay persistent for a long time.
In my experience this process can reproduce the problem quickly:
1. Open a post, create it, and save it.
2. Immediately re-edit the post (edit link on the post).
3. Make a small edit and re-save the post.
4. Repeat 2+3 twice more in sequence.
I kept track of Apache’s status using an apache-status page and noted the following:
With 1 save, wp-cron.php is spawned twice, with two http requests that are persistent for over 30 seconds.
With 2 saves, wp-cron.php is spawned eight times, but the requests are equally persistent as with 1 save.
With 3 saves, wp-cron.php is spawned over 20 times, which maxes out my small Apache server to its max_clients setting. This places the server into a swapping state which seems to make matters much worse — the wp-cron.php Apache processes then never release, and are constantly in a Responding state even after they begin serving other requests.
It may just be me, but I see no need to ever spawn more than one wp-cron.php fork at a time. I think I will be submitting this as a bug…
I believe the issue here is that “nobody knows what’s going on” — it’s a weird case. Even harder is finding any information on Apache crashes and debugging, or on this crazy problem of the maxed out load with Apache processes not releasing correctly… can’t find anything anywhere, except for other lost searchers posting cries for help…
Okay, here’s an interesting possible cause… I found an entry for wp-cron.php and my IP address in my Bad Behavior database table, which means that a local request for wp-cron.php (as does happen frequently) will be sent a 403 Forbidden!!
That could result in another kind of request loop that the above patch does not fix, but I’d call this a Bad Behavior bug and not a WordPress bug. I’ll be notifying them of it if it hasn’t already been fixed…
I’m interested to hear if any others experiencing this problem have Bad Behavior installed, and can find an entry for wp-cron.php in its database.
Personally I’ve disabled the plugin, and it seems to have fixed the problem completely. Requests to wp-cron.php in any sequence of saves now take about a second and then the server returns to normal. Finally!
Guys, I’m completely blank about this whole thing. Yesterday, my site was down due to this and I fixed it by upgrading the installation.
But I’m genuinely interested in learning more and more about this. Can anyone recommend a good site to learn ? 🙂
Problem solved for me, see: http://wordpress.org/support/topic/128800
Was a .htaccess rule blocking the whole process
Well I’m totally stumped on this one… I’ve read all the wp-cron issues and bad behavior. I’m running WP 2.2.3 and Bad Behavior 2.0.10.
All my HTTP requests for wp-cron.php come from my server’s IP (makes sense) and the HTTP return codes are 200. But my server’s IP is listed in the Bad Behavior database, so obviously it’s blocking wp-cron.php from working properly.
Anyone know how to fix it up?
If Bad Behavior is giving you problems, you can add your own IP to BB’s whitelist. Look in the BB folder and find the whitelist.inc.php file. Edit it with a text editor, it should be pretty obvious on how to whitelist an IP address.
@otto42
Thanks for the lead, believe it or not, I’d not actually dipped into the BB system folder, just the WP admin interface and the BB SQL table.
Now added server IP to whitelist.inc.php – I’ll check my logs on the next post.
For info to anyone with similar issues, I made 15 post edits on Sept 15th, so there were 15 wp-cron.php entries in the Apache log with HTTP 200 codes but also 15 identical date/time entries in the BB SQL table with the server IP.
blacklist.inc.php is also interesting…
If this fixes up the problem (and WP 2.2.3 slowing down to 20 secs on some admin funcs) I’ll post here.
So far, no further issues with wp-cron if I add the server IP to the Bad Behavior whitelist.
