Opened 3 years ago

Closed 3 years ago

Last modified 3 weeks ago

#11831 closed defect (bug) (wontfix)

Warning when wp-cron fails

Reported by: scribu Owned by: westi
Priority: normal Milestone:
Component: Warnings/Notices Version: 3.0
Severity: normal Keywords: cron fopen
Cc: tom@…, harrym, cyberhobo@…, eliotsykes, chriscct7@…

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 (1)

reasonable_cron_request_timeout.diff (603 bytes) - added by eliotsykes 3 years ago.
Patch to give cron http request a reasonable timeout of 1 second rather than 0.01 secs

Download all attachments as: .zip

Change History (25)

comment:1 follow-up: ↓ 2   dd323 years ago

Thats suppressed if WP_DEBUG is not enabled

comment:2 in reply to: ↑ 1   nacin3 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   dd323 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

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

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

Forgot I had WP_DEBUG enabled. Sorry.

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

  • Cc tom@… added
  • Cc harrym added

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.

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

  • 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?

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.

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

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

comment:15 follow-up: ↓ 16   westi3 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   nacin3 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.

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

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

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

I also found adding

define('ALTERNATE_WP_CRON', true);

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

  • 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

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"

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

  • Cc chriscct7@… added
Note: See TracTickets for help on using tickets.