One of our older legacy servers which gets no further updates or reconfigurations suddenly stopped resolving hostnames to IPs when PHP is executed within Apache. However, it still works fine when executed from the CLI.

From the RSS caches last modification time, I deduce that it stopped working on around Mar, 28th.

To reproduce the problem, I created a script using fsockopen() and it said "connection failed (errno 2)". I further reduced the problem to being related with a failed name resolution:

<?php $addr = gethostbyname("twitter.com"); echo "ADDR($addr)"; ?>

When I run this through Apache, the output is ADDR(twitter.com), which is wrong.

When I run this from the CLI, the output is ADDR(aaa.bbb.ccc.ddd) with varying IP addresses, as expected.

Nothing on the server setup has changed. CLI and Apache module share the same php.ini. PHP is version v4.4.9 with Zend Optimizer v2.5.10. Apache is v1.3.31.

I know the versions are old. But since nothing has been changed, a solution like "try to upgrade versions first" is no solution as the server's feature set/versioning is frozen and will be replaced soon. Still we need a solution.

If I run dig through the script, it works in both environments (mod_php and CLI) but this is more than an ugly hack as it would involve many edits and testing throughout the whole script base which is also undesired as the PHP application on the server is frozen, too, and only receives security updates. It will be replaced by a complete rewrite (on the new server).

But as the rewrite will take some time and successive replace parts of the legacy application, we need a fix for the resolver problem. I already googled a bit and while the problem is known, many did not find a fix. The fix to raise memory limits did not work. Restarts did not work. The resolver in mod_php just did stop working for no apparent reason. :-(

Update: I solved it meanwhile by fully stopping apache, waiting for a moment, then starting it again. But that doesn't explain the root cause for this behaviour (and thus there's no satisfying solution). So I leave this open.


Neither a graceful restart, nor a normal restart worked. I needed to fully stop apache, wait for all processes to finish, then start apache again. Problem solved. Since no one seems to find an explanation for the root cause of this behaviour I'm accepting my own solution.

  • 1
    Maybe your issue is not related to mod_php, but surely to apache : stackoverflow.com/questions/10008234/…
    – ıɾuǝʞ
    Apr 4 '12 at 10:39
  • 2
    I've activated logging at DNS server side, no request are received when resolving from Apache is KO.
    – ıɾuǝʞ
    Jul 8 '14 at 15:16
  • Same thing on Apache/2.4.6 (CentOS 7) PHP 7.0.9, only service httpd restart helped. Aug 19 '16 at 22:33
  • Still happened in Apache/2.4.25 (Fedora) with PHP 7.0.15
    – Ray Foss
    Feb 9 '17 at 21:33

The same here O.K when run from CLI, error when run through Apache. I guess this has something to do with changes into the name servers e.g. in /etc/resolv.conf. Somehow Apache (other programs are affected as well) do not check for changed name servers and are unable to resolve. This happens with me when i switch networks with my laptop. I have to manually stop apache, opera, firefox, etc in order for them to get the new name server settings.

  • Interesting hint, although changes to resolv.conf should usually picked up automatically by all programs using glibc. If I remember right we changed DNS settings a few weeks(!) before this problem occurred.
    – hurikhan77
    Apr 8 '12 at 19:13

From the comments at PHP.net manual on gethostbyname:

If name resolution fails with apache2, mod_chroot and php5, add LoadFile /lib/libnss_dns.so.2 to the mod_chroot config.


When using PHP and Apache in a chroot environment on RedHat Linux, I have found that I need to bind-mount /var/run/nscd to get this to work. Apparently, the socket in that directory is needed for all the DNS things.

  • No chroot, no apache 2. It's an old debian 3 system with custom-compiled apache and php. Well, I solved it meanwhile by fully stopping apache, waiting for a moment, then starting it again. But that doesn't explain the root cause for this behaviour. So I leave this open.
    – hurikhan77
    Apr 6 '10 at 19:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.