WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#7514 closed defect (bug) (fixed)

Fatal error when fsockopen times out

Reported by: azaozz Owned by:
Milestone: 2.7 Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: Cc:

Description

Was thinking to reopen #4779 but the last comment there asks for new tickets.

Warning: fsockopen() [function.fsockopen]: php_network_getaddresses: getaddrinfo
 failed: Name or service not known in .../wp-includes/http.php on line 466

Warning: fsockopen() [function.fsockopen]: unable to connect to api.wordpress.org:80
 (Unknown error) in .../wp-includes/http.php on line 466

Fatal error: Cannot use object of type WP_Error as array in .../wp-includes
/update.php on line 148

Attachments (5)

7514.diff (406 bytes) - added by santosj 7 years ago.
Error checking to update.php
7514.2.diff (2.2 KB) - added by santosj 7 years ago.
Adds checking for fsockopen to check for WP_DEBUG and silently drop warnings. Adds streams_set_timeout to fsockopen to help prevent long waits.
7514.r8645.diff (1.5 KB) - added by jacobsantos 7 years ago.
Type cast the $rtimeout? to try to fix the connection time out.
7514.r8653.diff (1.2 KB) - added by santosj 7 years ago.
Fix notice and add action for when fsockopen takes longer than timeout.
7514.r8653.2.diff (2.1 KB) - added by jacobsantos 7 years ago.
Disable fsockopen for 12 hours if it fails.

Download all attachments as: .zip

Change History (21)

comment:1 @santosj7 years ago

Are you on Windows? What PHP version are you using? It appears to try to look up the DNS info for api.wordpress.org, but fails to do so. The real problem, aside from what information you give me is that update.php isn't handling the WP_Error, when it should.

@santosj7 years ago

Error checking to update.php

comment:2 @santosj7 years ago

Need more information in order to test the fsockopen() issue. Patch should fix fatal error.

comment:3 @azaozz7 years ago

Think that would happen on any server, tested on Apache/2.2.6 Linux(Ubuntu) PHP/5.2.4. There were some routing/DNS issues at the ISP and most of the Net was inaccessible.

Part of the problem is update.php not handling WP_Error, but after fixing this the above warnings still show at the top of each admin page (after about 20 sec delay in loading), despite that WP_DEBUG is not defined. Perhaps it needs to fail graciously and with less timeout.

comment:4 @santosj7 years ago

Now that is something. It should fail after 3 seconds. That it is not is disturbing. I'm going to do some more research to find out what is happening that it is not timing out correctly. It seems to me that it should only take 9 seconds total.

I will do the same as with fsockopen as I did with fopen to ensure it doesn't output warnings. However, it will need to do so when WP_DEBUG is enabled in order to debug failures.

@santosj7 years ago

Adds checking for fsockopen to check for WP_DEBUG and silently drop warnings. Adds streams_set_timeout to fsockopen to help prevent long waits.

comment:5 follow-up: @santosj7 years ago

New patch should helpfully handle all over problems.

comment:6 @ryan7 years ago

(In [8644]) Adds checking for fsockopen to check for WP_DEBUG and silently drop warnings. Adds streams_set_timeout to fsockopen to help prevent long waits. Props santosj. see #7514

comment:7 in reply to: ↑ 5 @azaozz7 years ago

Replying to santosj:

New patch should helpfully handle all over problems.

It looks like it should work, but for some reason the delay in opening any admin page is still there. Passing false to 'use_fsockopen_transport' removes most delay (only 3 sec remains), otherwise there's about 20 sec delay.

Env: as above, server is blocked at the router, no Net access while testing.

@jacobsantos7 years ago

Type cast the $rtimeout? to try to fix the connection time out.

comment:8 @jacobsantos7 years ago

I want to say that the reason it is taking so long is that it has to loop through all of the other transports until it gets to fsockopen, but it appears that is not the case. It seems the other transports handle firewall blocking and lost of connections better than fsockopen.

If the patch doesn't work, then I'll have to say it is a fsockopen bug that is not obeying the connection timeout.

It also appears that you are supposed to set the stream timeout after you write. Not part of the issue, but will hopefully fix problems that may come up later.

comment:9 @azaozz7 years ago

You're right, it seems fsockopen doesn't obey the connect timeout for some reason. There's a note in the manual too: "Depending on the environment, the Unix domain or the optional connect timeout may not be available."

Perhaps the best way to handle this would be to not even use fsockopen if one of the other transports is available, even if it fails to connect/reaches the timeout. Then we can assume the target server is not accessible and stop further processing.

comment:10 follow-up: @jacobsantos7 years ago

Well, the issue then is that in my tests (see #4779 test suite zip), some of the transports would fail, read timeout while others would succeed. Um, it depends. The fall back is there, so that you aren't stuck with a transport that is always going to fail.

That would be the worse thing. I think that instead, the default behavior could be to fallback and then add something that allows for the fallback to not be used. This would instead call the first available callback and then return the response, whether it be WP_Error or response array.

What do you think?

comment:11 in reply to: ↑ 10 @azaozz7 years ago

Replying to jacobsantos:

That would be the worse thing. I think that instead, the default behavior could be to fallback and then add something that allows for the fallback to not be used. This would instead call the first available callback and then return the response, whether it be WP_Error or response array.

Yes, I think that should do it without limiting any functionality. Perhaps after the first failure of fsockopen we can add a temp option to disable it for lets say 24 hours. A small function that will keep the last disable time and set the 'use_fsockopen_transport' to false, then remove it when time has passed.

comment:12 @santosj7 years ago

I don't think it is a good idea to block fsockopen or disable it. If it takes 20 seconds, then it takes 20 seconds and hope that it isn't something that is run every time. Fsockopen is the fallback, meaning that if everything fails, then it has to be available.

If we block it because it takes too long, then it will be impossible to write to web sites. I think it should be plugin material. I'm going to add hooks in for plugins to decide whether it should be blocked.

@santosj7 years ago

Fix notice and add action for when fsockopen takes longer than timeout.

comment:13 @santosj7 years ago

Updated patch calls action only when elapsed time is greater than timeout is supposed to be. This allows for plugins to set whether the fsockopen transport should be disabled.

comment:14 @santosj7 years ago

I do understand this would be a lot easier if everyone used HTTP extension or PHP5.x. The HTTP extension is available for PHP 4.x.

comment:15 @azaozz7 years ago

Unfortunately when the remote server is not available this delay happens on every click in the admin, including ajax actions. Imagine api.wordpress.org being unavailable for some reason, there will be millions of WordPress installations running extremely slow...

Still think it's better option to disable fsockopen for 24 hours when it fails to connect. Of course it's a fallback and it's needed, but when this fallback fails too, we can wait few hours before trying it again.

@jacobsantos7 years ago

Disable fsockopen for 12 hours if it fails.

comment:16 @azaozz7 years ago

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

(In [8654]) Disable fsockopen for 12 hours if it fails. Props jacobsantos, fixes #7514

Note: See TracTickets for help on using tickets.