Bug #11058 [Com]: php_network_getaddresses: getaddrinfo failed

Edit report at https://bugs.php.net/bug.php?id=11058&edit=1 ID: 11058 Comment by: anael dot favre at gmail dot com Reported by: pat at mail dot rit dot edu Summary: php_network_getaddresses: getaddrinfo failed Status: Not a bug Type: Bug Package: Network related Operating System: OpenBSD 2.6 PHP Version: 4.0.6 Block user comment: N Private report: N New Comment: I have exactly the same problem as you kostello. I have 3 virtual machines and one hos having this problem since 2-3 days in production. All are Ubuntu 16.04.2, php7.0-fpm, nginx running production servers. It is really annoying as it also break external php debugger tools (like sentry, bugsnag) so we are completely blind when its happen (and have to check the logs). I first think about a downtime of the DNS server, and then php cache it and return bad values until a php-fpm restart. My servers are running at OVH (france) and you ? Previous Comments: ------------------------------------------------------------------------ [2017-03-24 03:45:25] kostello at gmail dot com To heiglandreas: I have tried to update my system (Ubuntu 14.04 LTS) and there is no mention of such an update, unfortunately. What's more, the two VMs that encountered the error were not updated for several days prior to the problem. And finally, the name resolution error occurred only within PHP - other attempts to replicate the problem outside of PHP failed. I am not saying you are wrong, on the contrary you are in a much better place than myself to know what's happening, I am just providing additional elements for you to consider. It shall be noted that I haven't encountered the error again since the last time I restarted PHP-FPM on either VM. To spam2 at rhsoft dot net: I do not believe this applies to my case. The uptime on the first VM was several days, with few daily HTTP requests (about 1000-2000) and very few of these required name resolution - the file_get_contents($url) instruction is used in only specific part of my application. The second VM had about 12 hours uptime when the error occurred and had received less than 50 HTTP requests. I shall add that the two VMs are on two completely separate network, in different countries, and once again outside of PHP everything was working perfectly fine. Also, no, I did not update server components before the errors occurred. I did not do anything in particular. I wish my bash_history file had time stamps to show you I am talking in good faith. ------------------------------------------------------------------------ [2017-03-23 17:37:41] heiglandreas@php.net This is an issue on the Ubuntu-side! They rolled out a faulty update. https://launchpad.net/ubuntu/+source/glibc/2.23-0ubuntu7 This is NOT a PHP-Issue! ------------------------------------------------------------------------ [2017-03-23 17:08:43] spam2 at rhsoft dot net And i still bet it is not a problem on the php side - disable response rate limiting on your nameserver, switch to. A different or setup your own resolver I had a similar issue because I thought php at least would cache the answers at least within a loop doing file_get_contents() over a large url-array all within the same domain So when your page has such code and some bot is running wild you produce the dns request for each and every pagecall and so easily exceed response limits When you use the curl extension identical dns queries are at least cached within the same request ------------------------------------------------------------------------ [2017-03-23 16:33:16] chilieu dot me at gmail dot com This happened to our server again in 24hrs Our is running Ubuntu 16.04 LTS, nginx, PHP-FPM, PHP 7.0.15-1+deb.sury.org~trusty+1 when I was trying to use file_get_contents to get estimation shipping fee from ups the only way I can fix it is restart php ------------------------------------------------------------------------ [2017-03-23 08:56:21] spam2 at rhsoft dot net did you guys who are affected install updates on your machines which replaced from webserver/php loaded libraries without re-starting the webserver? updating "nss" without hard restart httpd was the only time in the past decade where is saw similar issues - hence don't appyl autoupdates blindly and restart services with orphaned filehandles - especially services which are forking or have multiple threads ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=11058 -- Edit this bug report at https://bugs.php.net/bug.php?id=11058&edit=1