Make WordPress Core

Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#3713 closed defect (bug) (fixed)

Missing wp-cron.php might put huge stress on the Server

Reported by: jan's profile Jan Owned by:
Milestone: 2.1.1 Priority: high
Severity: critical Version: 2.1
Component: General Keywords: has-patch wp-cron cron recursive call heavy load server scheduler
Focuses: Cc:

Description (last modified by foolswisdom)

It happened to me when I forgot uploading wp-cron.php after updating to 2.1.

The Scheduler tried to reach wp-cron.php which wasn't found. The request was therefore directed to index.php, recursively triggering the scheduler again.

I noticed when I received a mail from my hoster about shutting my site down because it caused too much load on the server.

Now this shouldn't happen under normal circumstances but the effect is quite severe when it happens. Issues with .htaccess could cause this too. I haven't completely checked out the cron mechanism yet but this seems weakly designed somehow.

A quick solution that comes to my mind right now would be to check for the GET Path before triggering the call to the wp-cron.php. If we are already handling a wp-cron request, something must have gone wrong and wp-cron should not be called again in the current session.
This is an ugly hack, I hope someone comes up with something smarter.

EXAMPLE OF SYMPTOM:

mar jan 30 11:22:45 CET 2007 : sainteli04 : Query 12 SELECT option_name,
option_value FROM cv_options WHERE autoload =
'yes'                              |
mar jan 30 11:22:45 CET 2007 : sainteli04 : Query 12 SELECT option_name,
option_value FROM cv_options WHERE autoload =
'yes'                              |
mar jan 30 11:22:45 CET 2007 : sainteli04 : Query 12 SELECT option_name,
option_value FROM cv_options WHERE autoload =
'yes'                              |
mar jan 30 11:22:45 CET 2007 : sainteli04 : Query 12 SELECT option_name,
option_value FROM cv_options WHERE autoload =
'yes'                              |
mar jan 30 11:22:45 CET 2007 : sainteli04 : Query 11 SELECT option_value
FROM cv_options WHERE option_name =
'siteurl'                                    |
mar jan 30 11:22:47 CET 2007 : sainteli04 : Killed 15 SELECT   cv_posts.*
FROM cv_posts  WHERE 1=1  AND post_name = 'wp-cronphp' AND (post_type =
'post')  |
mar jan 30 11:22:47 CET 2007 : sainteli04 : Killed 15 SELECT   cv_posts.*
FROM cv_posts  WHERE 1=1  AND post_name = 'wp-cronphp' AND (post_type =
'post')  |
mar jan 30 11:22:47 CET 2007 : sainteli04 : Killed 15 SELECT   cv_posts.*
FROM cv_posts  WHERE 1=1  AND post_name = 'wp-cronphp' AND (post_type =
'post')  |
mar jan 30 11:22:47 CET 2007 : sainteli04 : Killed 15 SELECT option_name,
option_value FROM cv_options WHERE autoload =
'yes'                              |
mar jan 30 11:22:50 CET 2007 : sainteli04 : Killed 17 SELECT   cv_posts.*
FROM cv_posts  WHERE 1=1  AND post_name = 'wp-cronphp' AND (post_type =
'post')  |
mar jan 30 11:22:50 CET 2007 : sainteli04 : Killed 17 SELECT   cv_posts.*
FROM cv_posts  WHERE 1=1  AND post_name = 'wp-cronphp' AND (post_type =
'post')  |
mar jan 30 11:22:50 CET 2007 : sainteli04 : Killed 17 SELECT   cv_posts.*
FROM cv_posts  WHERE 1=1  AND post_name = 'wp-cronphp' AND (post_type =
'post')  |
mar jan 30 11:22:50 CET 2007 : sainteli04 : Killed 17 SELECT option_name,
option_value FROM cv_options WHERE autoload =
'yes'                              |

Attachments (1)

wp-cron-prevent-infinite-loop.php (421 bytes) - added by markjaquith 18 years ago.

Download all attachments as: .zip

Change History (10)

#1 @markjaquith
18 years ago

  • Milestone set to 2.1.1
  • Priority changed from normal to high
  • Severity changed from normal to critical

Ouch. Nasty bug. Thanks for the nice report.

Actually, I don't really have a problem with your solution. Check my (untested) patch. Is this what you meant?

#2 @Jan
18 years ago

Yes, that's what I had on my mind.

#3 @charleshooper
18 years ago

  • Keywords has-patch added

#4 @markjaquith
18 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [4834]) Prevent a missing wp-cron.php from causing an infinite loop. Props jan. fixes #3713

#5 @markjaquith
18 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

That was a commit for /trunk/ but this needs to be fixed for 2.1.1

Would like another set of eyes on this before putting it into 2.1.1

#6 @foolswisdom
18 years ago

  • Description modified (diff)

#7 @foolswisdom
18 years ago

  • Description modified (diff)

#8 @markjaquith
18 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [4850]) Prevent a missing wp-cron.php from causing an infinite loop. Props jan. fixes #3713

#9 @trisweb
18 years ago

I just want to add a comment to this, not reopen. This kind of behavior can also be caused by the Bad Behavior plugin placing wp-cron.php in its blacklist, thereby 403'ing local requests to it.

Not sure if WordPress wants to block this possible condition, but even though I consider it a bug in Bad Behavior and have notified the developer, I suggest we find the cause of the infinite request loop and stop it. As a general rule, preventing Apache from crashing even in obscure cases is a Good Thing.

I've done a write-up here if anyone's curious.

http://www.trisweb.com/archives/2007/03/17/wordpress-wp-cronphp-and-bad-behavior-apache-crash/

Let me know if you want me to open a new bug. Thanks.

Note: See TracTickets for help on using tickets.