PHP: gethostbyname() suddenly no longer resolves names to IPs when run in Apache

5,622

Solution 1

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.

Solution 2

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.

Share:
5,622

Related videos on Youtube

hurikhan77
Author by

hurikhan77

Updated on September 17, 2022

Comments

  • hurikhan77
    hurikhan77 almost 2 years

    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.

  • hurikhan77
    hurikhan77 about 14 years
    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.
  • ıɾuǝʞ
    ıɾuǝʞ about 12 years
    Maybe your issue is not related to mod_php, but surely to apache : stackoverflow.com/questions/10008234/…
  • hurikhan77
    hurikhan77 about 12 years
    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.
  • ıɾuǝʞ
    ıɾuǝʞ almost 10 years
    I've activated logging at DNS server side, no request are received when resolving from Apache is KO.
  • Maxim Mazurok
    Maxim Mazurok almost 8 years
    Same thing on Apache/2.4.6 (CentOS 7) PHP 7.0.9, only service httpd restart helped.
  • Ray Foss
    Ray Foss over 7 years
    Still happened in Apache/2.4.25 (Fedora) with PHP 7.0.15