Fatal error when fsockopen times out

[azaozz]

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

[santosj]

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.

[santosj]

Error checking to update.php

[santosj]

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

[azaozz]

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.

[santosj]

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.

[santosj]

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

[santosj]

New patch should helpfully handle all over problems.

[ryan]

(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

[azaozz]

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.

[jacobsantos]

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

[jacobsantos]

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.

[azaozz]

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.

[jacobsantos]

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?

[azaozz]

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.

[santosj]

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.

[santosj]

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

[santosj]

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.

[santosj]

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.

[azaozz]

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.

[jacobsantos]

Disable fsockopen for 12 hours if it fails.

[azaozz]

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