php_network_getaddresses: getaddrinfo failed

[harry2cool]

Suddenly we get errors connecting to our Payment Gateways

======================
PHP Warning: fopen(): php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution in
PHP Warning: fopen(http://quote.yahoo.com/d/quotes.csv?...&f=l1&e=.csv): failed to open stream: php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution
PHP Warning: fread() expects parameter 1 to be resource, boolean given in
PHP Warning: fclose() expects parameter 1 to be resource, boolean given in
=============

These errors show on Custom Files.

Our host says there is no error with Curl.

What can we do ?

[harry2cool]

On paypal we get " Couldn't resolve host 'api-3t.paypal.com"

This looks like host issue, but they are not admitting, what can we tell them ?

[lruskauff]

Read this post to see if it helps, especially Dr. byte part.

Could it be that is didn't find the yahoo link ? Are you still getting this error? When you say that they show on custom files, what exactly do u mean?

Lruskauff

[harry2cool]

Well the issue automatically resolved.
Was not able to determine the cause thought, if this happens again will still be clueless.
Thanks

[RodG]

Well the issue automatically resolved.
Was not able to determine the cause thought, if this happens again will still be clueless.
Thanks

The issue you had is related to DNS lookups.
It has nothing to do with cURL.
It has nothing to do with any code or any other aspect of the Web site,

The problem is either with your hosts server (DNS resolvers not functioning) or the DNS servers where the lookups are taking place.

The errors aren't particularly unusual and do generally 'fix themselves' in due course.
There was once a time when DNS (server) issues could be automatically ruled out of the equation (due to the requirement that all domains needed a minimum of two Name servers, each on a different network). Alas, times have changed and it is now possible to have both required servers to not only be on the same network, but even the same host (via virtualisation). IOW, where there was once a required redundancy to provide network stability we now have millions of sites operating with a single point of failure.
This is called 'progress'
Cheers
RodG

[lhungil]

Some of the PHP <==> Apache methods (and specific versions) are known to cache DNS information until Apache is restarted... So in addition to what RodG posted (the usual causes)... If network topography changes, the hosting provider may in some cases need to restart Apache.

[RodG]

Some of the PHP <==> Apache methods (and specific versions) are known to cache DNS information until Apache is restarted... So in addition to what RodG posted (the usual causes)... If network topography changes, the hosting provider may in some cases need to restart Apache.

But grasshopper, if the DNS data has been cached then the "Couldn't resolve host" couldn't/wouldn't exist.

Yeah, sure the data may be stale, but the lookup will still resolve.

Furthermore, restarting Apache doesn't clear out the DNS cache, so even if apache itself had its own DNS caching (which it doesn't) it won't solve any issues caused by stale data.

Cheers
RodG

[harry2cool]

Correct RodG, restarting Apache did not help.

If we face an issue like this again, can we tell the host to do anything OR just wait ?

Thanks for the explanation.

[lhungil]

But grasshopper, if the DNS data has been cached then the "[COLOR=#333333]Couldn't resolve host" couldn't/wouldn't exist. ...

Note I said "DNS information", not "DNS entries".


For example when the DNS nameserver's address is cached or "/etc/resolv.conf" is cached by a running process. Now the process will continue to try to talk to the cached nameserver until the cache expires or the running process is restarted. When this happens, unix "host", "dig", and other commandline tools will report no problem resolving DNS (they awill use the new nameserver), but a process already started (such as Apache + PHP) will error out. I've seen this occur before (usually with servers configured via DCHP or when external network providers changed - and when various best practices for high availability are not followed).


It was a few years ago when I last saw this (and I do not remember the versions of Apache + PHP involved, nor the bridge used to communicate betwen them). But I do remember the "quick fix" was to stop and start Apache (which resulted in the new "DNS information" being immediately used by Apache + PHP).

[lhungil]

... If we face an issue like this again, can we tell the host to do anything OR just wait ? ...

Hopefully it was a "fluke"...

Just my $0.02... But if the hosting provider has continuing issues with their servers or network, I'd do more than just asking the host to "fix" things... I'd be looking for a hosting provider better suited to host my business...