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?s=USDINR=X&f=l1&e=.csv%29: 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 ?

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 ?

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

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

harry2cool:

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

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.

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.

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

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.

RodG:

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

harry2cool:

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

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.

It's always worth submitting a fault report for the most speedy fix. Some hosts won't even look into a problem unless they receive multiple reports, and as the saying goes 'the squeaky wheel gets the grease'

Having said that, resolver issues are probably more common than most people would realise (especially on a server rather than a client machine due to the frequency (or lack of) the need for its use (clients use them constantly, servers only need them when the hosted website needs to connect to a 3rd party server Eg, PayPal or shipping quotation servers, so a problem there could exist for considerable time before noticed and reported)

The actual problem can't be avoided, short outages are often caused by simple updates, and/or when the cached data gets 'dumped' and/or refreshed (often on a daily basis for data logging purposes) IOW, the problem is inevitable and usually so shortlived that no one will notice. It's only worth reporting if it persists for a couple of minutes or more.

Cheers
RodG

lhungil:

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

Classic backflip/squirm.
I'm going to save your dignity by not commenting on the inaccuracies and the comparison between apples and oranges that you've introduced with you introduction of the dig/host commands.

I will however state that I did a little further research after posting my earlier reply (the idea that Apache cached DNS data, information, records, or whatever you wish to call it) really didn't sit well with me), and guess what. It doesn't.
The outgoing requests (where the resolver issues, as being discussed, actually apply, is a function of cURL (or some other process that is totally unrelated to The Apache web server) , so restarting Apache could never resolve this particular issue.

The only time Apache ever needs to perform a DNS lookup is... Hmmm, never (I was going to say when redirects are employed, but even the lookups for this is handled client side, not server side).

Sorry.
RodG

Interesting. I believe the DNS lookups are offloaded (usually to the OS).

No squirming going on here, just stating a behavior I observed in the past (before I was active on the Zen Cart forums).

To clarify, I encountered "php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution" under Apache + PHP when:

A) Apache was started before an external Internet connection was available (and no DNS nameserver was specified), a PHP script via Apache resulting in a getaddr() call was run, the external Internet connection was started at a later time, and subsequent calls (after the external connection was operational) to the same PHP script via Apache continued to report the same message.

B) Apache was started and DNS was working fine (and again the PHP script was run via Apache). A DCHP request resulted in a IP, subnet, and DNS nameserver change (and the old nameserver was no longer reachable).

In both of the above cases, calling the same PHP script via cli (or using dig) worked (although Apache + PHP did not). Not sure why, but something appeared to be caching when running under Apache + PHP, because a stop + start of Apache resolved the issue. Evidently others have reported similiar behavior...

Of course I've seen the same message far more often for the common causes RodG has already mentioned (and I agreed with back in my first post).

lhungil:

Interesting. I believe the DNS lookups are offloaded (usually to the OS).

Yup. That Is exactly right (well, not so much the os, but the resolver libraries. Close enough though) , and that is exactly the point I'm making. The problem isn't Apache 'caching DNS whatever'

As before the rest of your post relates to things that are completely irrelevant to the "Couldn't resolve host" As per this discussion. The error that you have now mentioned "temporary failure in name resolution" is a whole new ballgame.

Why are you trying to make such a simple problem into something that it isn't?

I just love/hate the way that I can state a simple fact "if the DNS data has been cached then the "Couldn't resolve host" couldn't/wouldn't exist" could turn into a discussion that shouldn't exist, yet when when I ask for an "argument" (or more specifically peoples thoughts how a diagnosis I've made on demonstrated data must clearly be wrong, but I can't see where, so I seek further input or ideas, I get a total of zero replies. What's the deal with that?
FYI, I'm referring to another thread where enabling SSL on a site led to a $10k loss in sales in a single month).

Doesn't make sense to me at all. <sigh>.

RodG:

... The error that you have now mentioned "temporary failure in name resolution" is a whole new ballgame. ...
The first post in this thread referenced the same message. Just wanted to mention a weird quirk I've encountered which could be another possibility (and why the post mentioned one of the reasons you gave were more common) .Probably should have typed out a longer explaination, but have been away from a full keyboard for a few days.

RodG:

... when I ask for an "argument" (or more specifically peoples thoughts how a diagnosis I've made on demonstrated data must clearly be wrong, but I can't see where, so I seek further input or ideas, I get a total of zero replies. What's the deal with that? FYI, I'm referring to another thread where enabling SSL on a site led to a $10k loss in sales in a single month)...
That specific thread and the data are rather confounding. I've not encountered anything similiar, so could only speculate wildly... Maybe I'll take a closer read when I am in front of a larger screen and a keyboard. ;-)