Warning when wp-cron fails

[scribu]

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?

[dd32]

Thats suppressed if WP_DEBUG is not enabled

[nacin]

Replying to dd32:

Thats suppressed if WP_DEBUG is not enabled

E_NOTICE is supressed, but this looks like an E_WARNING.

[dd32]

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

​http://core.trac.wordpress.org/browser/trunk/wp-includes/http.php#L1006

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

[nacin]

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

[dd32]

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.

[scribu]

Forgot I had WP_DEBUG enabled. Sorry.

[harrym]

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.

[nacin]

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.

[cyberhobo]

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.

[eliotsykes]

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);
else
  $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?

[eliotsykes]

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.

[eliotsykes]

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.

[eliotsykes]

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

[westi]

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)

[nacin]

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.

[hakre]

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

[hakre]

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

[cyberhobo]

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

[scribu]

I also found adding

define('ALTERNATE_WP_CRON', true);

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

[theozero]

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

[nico23]

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"

[chriscct7]

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

[reyncor]

@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.

[SergeyBiryukov]

Related: #23133

[SergeyBiryukov]

#25223 was marked as a duplicate.

[jemaltz]

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.

[chriscct7]

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]

Added custom error handler to provide more information to site admins

[peterwilsoncc]

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.

[johnbillion]

Closing as above.