Make WordPress Core

Opened 14 years ago

Closed 2 years ago

#11831 closed defect (bug) (invalid)

Warning when wp-cron fails

Reported by: scribu's profile scribu Owned by: westi's profile westi
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Cron API Keywords: needs-patch
Focuses: Cc:


Running 3.0 alpha I sometimes get this warning just at the top of admin pages:

Warning: fopen(http://localhost/wp/wp-cron.php?doing_wp_cron) [function.fopen]: failed to open stream: HTTP request failed! in /home/cristi/svn/wp/wp-includes/http.php on line 1009

I didn't notice it in WP < 2.9. Perhaps it should be suppressed?

Attachments (2)

reasonable_cron_request_timeout.diff (603 bytes) - added by eliotsykes 14 years ago.
Patch to give cron http request a reasonable timeout of 1 second rather than 0.01 secs
wp-cron.php.patch (1.1 KB) - added by Scott Herbert 10 years ago.
Added custom error handler to provide more information to site admins

Download all attachments as: .zip

Change History (37)

#1 follow-up: @dd32
14 years ago

Thats suppressed if WP_DEBUG is not enabled

#2 in reply to: ↑ 1 @nacin
14 years ago

Replying to dd32:

Thats suppressed if WP_DEBUG is not enabled

E_NOTICE is supressed, but this looks like an E_WARNING.

#3 @dd32
14 years ago

Sorry, Maybe i should've included a code reference :)

1006	                if ( !WP_DEBUG )
1007	                        $handle = @fopen($url, 'r', false, $context);
1008	                else
1009	                        $handle = fopen($url, 'r', false, $context);

The same happens for most other transports: fsockopen, fopen, HTTP Extension

#4 @nacin
14 years ago

Ahh, completely forgot about that. :-) I should have remembered, I've patched those lines before.

#5 @dd32
14 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I'm thinking this is a wontfix, Developers need to be aware of failure messages, It shouldnt occur for regular users.

I'm closing as wontfix for that reason for now, If someone feels strongly against that reasoning, feel free to reopen.

#6 @scribu
14 years ago

Forgot I had WP_DEBUG enabled. Sorry.

#7 @harrym
14 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Well, hang on a minute. I agree it shouldn't be supressed when WP_DEBUG is on, but that's not really the point. Why's it failing in the first place? Can't we just fix it?

I also get this intermittently and it's rather irritating. I've taken to doing echo "" > wp-cron.php just to make it shut up.

#8 @holizz
14 years ago

  • Cc tom@… added

#9 @harrym
14 years ago

  • Cc harrym added

#10 @nacin
14 years ago

Sometimes, HTTP requests fail. In this case, in particular, on localhost. That's part of the reason why we suppress them.

I've personally never seen this. I think it's isolated to this server configuration.

#11 @cyberhobo
14 years ago

  • Cc cyberhobo@… added

I believe I get this every time wp-cron.php is requested on my local XAMPP install. Usually I just reload whatever I'm looking at and the request isn't repeated, but it would be nice to know the cause. I'll post back if I find anything.

#12 @eliotsykes
14 years ago

  • Cc eliotsykes added
  • Version changed from 2.9.1 to 3.0

I get this too in Wordpress 3.0-RC1 when running on localhost.

I can replicate it the error message consistently if I delete the cron options after every request by running this SQL:

delete from wp_options where option_name like '%cron%';

My assumption is that doing this causes the cron function to be run on every request. It looks like these options suppress cron from running again for some time.

For me it was happening on line 1045 of class-http.php

if ( !WP_DEBUG )
  $handle = @fopen($url, 'r', false, $context);
  $handle = fopen($url, 'r', false, $context); // Line 1045

I did some research and found that 2 common reasons fopen fails are:

  1. user-agent being the standard PHP one being blocked by web server. I tried a different user-agent, this did not fix the bug
  2. allow_url_fopen being set to false. It is true on my system so this is not the cause for me.

So I'm not sure where to go from here. Perhaps the test() function for WP_Http_Streams needs some extra tests?

#13 @eliotsykes
14 years ago

Tried out a couple more things, narrowed it down to a problem with Streams.

In class-http.php, if I force WP_Http_Fopen to be used instead of WP_Http_Streams then the error message does not happen.

So the bug happens when fopen is called with a Streams context.

This boils down to the difference between these two lines:

$handle = fopen($url, 'r'); // Works! About line 860 in class-http.php
$handle = fopen($url, 'r', false, $context); // Bug! Line 1045 class-http.php

I'm using PHP version 5.2.6-3 and allow_url_fopen is true. Apache version is 2.2.11.

So my guess is that the array options given to create the $context variable is causing problems. Perhaps playing with these options might yield some results for someone who has more experience with PHP streams, for now I'm going to live with this issue.

#14 @eliotsykes
14 years ago

  • Keywords cron fopen added

Its the timeout.

It defaults to 0.01 seconds on line 234 of wp-includes/cron.php which seems very short.

In class-http.php the timeout default is 5 seconds.

So I increased the timeout to 1.0 seconds and this works fine for me now, no longer get the error message.

wp_remote_post( $cron_url, array('timeout' => 1.0, 'blocking' => false, 'sslverify' => apply_filters('https_local_ssl_verify', true)) );

I've got a patch and will submit it if I can figure out how to.

14 years ago

Patch to give cron http request a reasonable timeout of 1 second rather than 0.01 secs

#15 follow-up: @westi
14 years ago

The cron timeout is that short for a good reason.

We don't care about whether or not the request completes we just want to kick it off and then carry on with the current page load.

If a transport can't cope with sub 1 second timeouts then we should fix the http transport to have a low end cap (at least one does already I believe)

#16 in reply to: ↑ 15 @nacin
14 years ago

Replying to westi:

If a transport can't cope with sub 1 second timeouts then we should fix the http transport to have a low end cap (at least one does already I believe)

Yep, curl does because it can't handle floats. See also #8923.

#17 @hakre
13 years ago

If non-blocking calls could be used (when it's possible to better check for), then the timeout could be extended a bit: #11613, #14786

#18 @hakre
13 years ago

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

Closing as of this discussion. If that's not pleasing for someone, feel free to re-open.

#19 @cyberhobo
13 years ago

p.s.: for me (XAMPP on Vista), enabling php_curl in php.ini made the warnings go away.

#20 @scribu
13 years ago

I also found adding

define('ALTERNATE_WP_CRON', true);

to wp-config.php makes the notice go away.

#21 @theozero
11 years ago

  • Keywords changed from cron, fopen to cron fopen

Was running into this problem on a new (ubuntu) server. The problem was php-curl was not installed (and enabled).
This may be the case if you set up a server from scratch and just forgot to include it.

My fix was "apt-get install php5-curl"

hopefully that helps someone else getting this error

#22 @nico23
11 years ago

Thanks @theozero yes that helped me.

I can confirm this to be working on Ubuntu 12.04 and 13.04. CURL is not installed by default if you install the LAMP stack or just PHP. Usually you'll need a sudo in front of this command.

"sudo apt-get install php5-curl"

#23 @chriscct7
11 years ago

WP 3.6, CURL enabled for both Apache and PHP still getting these warnings. Running a WAMPServer stack. Scribu's solution seems to work.

#24 @chriscct7
11 years ago

  • Cc chriscct7@… added

#25 @reyncor
10 years ago

@theozero @nico23
The fix worked, but why is the error so cryptic.

I think this should be reopened and have a proper error thrown. I have a fairly vanilla ubuntu 13.04 LAMP and I get the error all the time... randomly.

It took me over 15 minutes to find this bug, and than read through this entire bug, before I found the problem. The fact that php-curl isn't installed should be part of the error.

Last edited 10 years ago by reyncor (previous) (diff)

#27 @rodrigosprimo
10 years ago

  • Cc rodrigosprimo@… added

#28 @SergeyBiryukov
10 years ago

#25223 was marked as a duplicate.

#29 @jemaltz
10 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Re-opening because of my experience with this issue.

In a nutshell, I migrated a WordPress site (two, actually) to a different server, and initial site loads were taking 18+ seconds, while subsequent loads were < 1 second. After a while troubleshooting, I enabled WP_DEBUG and saw this warning ("doing_wp_cron" had a value in the query string). Installing php5-curl resolved it, and now initial site loads are < 2 seconds.

For more information, part of my troubleshooting was disabling all plug-ins, and changing the theme to Twenty Ten, and still the load issues persisted.

Once I came across this thread, I recalled that one of my installed plugins depends on php5-curl for functionality. Perhaps there is a coding issue with that plugin, since I was still impacted by this after disabling the plugin, but it nonetheless underlines the fact that this is an important issue with real performance side effects.

Site loads were 18+ seconds any time Apache was restarted, or the site hadn't been accessed in the previous ~30 seconds. This is on WordPress 3.6.1.

#30 @chriscct7
10 years ago

Plugin and theme changes wouldn't have made a difference.

Did you try adding the recommended define('ALTERNATE_WP_CRON', true); to the wp-config.php file of your install?

@Scott Herbert
10 years ago

Added custom error handler to provide more information to site admins

#31 @SergeyBiryukov
10 years ago

  • Keywords cron fopen removed
  • Milestone set to Awaiting Review

#32 @nacin
10 years ago

  • Component changed from Warnings/Notices to Cron

#33 @chriscct7
8 years ago

  • Keywords needs-patch added

#34 @peterwilsoncc
6 years ago

Is this still an issue since the WordPress 4.6 switch to Requests?

I'm unable to reproduce, many of the lines referenced no longer exist.

#35 @johnbillion
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

Closing as above.

Note: See TracTickets for help on using tickets.