WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 19 months ago

#11831 reopened defect (bug)

Warning when wp-cron fails

Reported by: scribu Owned by: westi
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.0
Component: Cron API Keywords:
Focuses: Cc:

Description

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 5 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 22 months ago.
Added custom error handler to provide more information to site admins

Download all attachments as: .zip

Change History (34)

comment:1 follow-up: @dd326 years ago

Thats suppressed if WP_DEBUG is not enabled

comment:2 in reply to: ↑ 1 @nacin6 years ago

Replying to dd32:

Thats suppressed if WP_DEBUG is not enabled

E_NOTICE is supressed, but this looks like an E_WARNING.

comment:3 @dd326 years ago

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

comment:4 @nacin6 years ago

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

comment:5 @dd326 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.

comment:6 @scribu6 years ago

Forgot I had WP_DEBUG enabled. Sorry.

comment:7 @harrym5 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.

comment:8 @holizz5 years ago

  • Cc tom@… added

comment:9 @harrym5 years ago

  • Cc harrym added

comment:10 @nacin5 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.

comment:11 @cyberhobo5 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.

comment:12 @eliotsykes5 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);
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?

comment:13 @eliotsykes5 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.

comment:14 @eliotsykes5 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.

@eliotsykes5 years ago

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

comment:15 follow-up: @westi5 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)

comment:16 in reply to: ↑ 15 @nacin5 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.

comment:17 @hakre5 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

comment:18 @hakre5 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.

comment:19 @cyberhobo5 years ago

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

comment:20 @scribu5 years ago

I also found adding

define('ALTERNATE_WP_CRON', true);

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

comment:21 @theozero3 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

comment:22 @nico232 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"

comment:23 @chriscct72 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.

comment:24 @chriscct72 years ago

  • Cc chriscct7@… added

comment:25 @reyncor2 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 2 years ago by reyncor (previous) (diff)

comment:27 @rodrigosprimo2 years ago

  • Cc rodrigosprimo@… added

comment:28 @SergeyBiryukov2 years ago

#25223 was marked as a duplicate.

comment:29 @jemaltz22 months 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.

comment:30 @chriscct722 months 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 22 months ago

Added custom error handler to provide more information to site admins

comment:31 @SergeyBiryukov22 months ago

  • Keywords cron fopen removed
  • Milestone set to Awaiting Review

comment:32 @nacin19 months ago

  • Component changed from Warnings/Notices to Cron
Note: See TracTickets for help on using tickets.