php_network_getaddresses: getaddrinfo failed

[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]

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

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

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]

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

[RodG]

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

[lhungil]

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