I've got a tiny bit of code running on my mac dev server that fails with a "couldn't resolve host" error. I've tried typing 'curl http://www.domain.com/file.txt' at the command line and it echoes out the entire file with no problems so I know it's not a network problem. The code looks pretty straightforward:

$csv = 'http://www.domain.com/file.txt';
$tmp_file_name = 'tmp/'.numOnly(microtime(true)).'.txt';
$ch = @curl_init();
$fp = @fopen($tmp_file_name, 'w');
@curl_setopt($ch, CURLOPT_URL, $csv);
@curl_setopt($ch, CURLOPT_FILE, $fp);
@curl_setopt($ch, CURLOPT_FAILONERROR, 0);
@curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 8);
@curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
@curl_setopt($ch, CURLOPT_TIMEOUT, 16);
@curl_setopt($ch, CURLOPT_VERBOSE, 1);
if(@curl_exec($ch) === false){
	die(@curl_error($ch));
}else{
    echo 'success!';
}
@curl_close($ch);
@fclose($fp);

My curl settings in phpinfo look like this:

cURL support 	enabled
cURL Information 	7.16.4
Age 	3
Features
AsynchDNS 	No
Debug 	No
GSS-Negotiate 	Yes
IDN 	No
IPv6 	Yes
Largefile 	Yes
NTLM 	Yes
SPNEGO 	No
SSL 	Yes
SSPI 	No
krb4 	No
libz 	Yes
CharConv 	No
Protocols 	tftp, ftp, telnet, dict, ldap, http, file, https, ftps
Host 	i386-apple-darwin9.0
SSL Version 	OpenSSL/0.9.7l
ZLib Version 	1.2.3 

Can anyone suggest a good reason why curl would fail when run under apache while it works fine from the command line?

    Nothing jumps out at me. Have you tried it with all error reporting turned on and without the "@" operators, just to see if it has anything interesting to tell you?

      I have and was able to determine that the tmp folder was not writeable. Once I fixed that, all of the errors were gone.

      I ran this script just fine on a different machine so if the permissions are set up correctly, it should work.

      I think the problem is either in the DNS configuration of my dev box, in the PHP configuration, or is due to a problem between PHP and cURL. I've googled quite a bit and have checked most of the PHP config stuff and it seems just fine. I saw some hints that certain versions of php (after 5.2.6) had some difficulty with older versions of cURL.

      Totally puzzling.

        I have no answer, but perhaps you or someone else can make something of this.

        I happen to have the same issue with my dev environment, while it works for test and production. The dev machine is able to resolve addresses outside of PHP (e.g. by ping or tracert). However, in PHP it's not just cUrl that fails but anything that needs to resolve an address such as file_get_contents('http:...').

        Also, I noticed that my test environment runs PHP 5.3.3 (more recent than 5.2.6) with cUrl 7.15.5 (older than yours), so unless there was issues with one or more specific versions, this isn't the cause.

        However, running the same script (file_get_contents('http://...')) from CLI works, while it fails under apache. And it was executed using the same user in both cases.

          So I posted in the pecl-dev list at php.net and someone has responded but no solution yet.

          He asked me to run this script:

          <?php
          $ip = gethostbyname('www.google.com');
          var_dump($ip);
          ?>
          

          which outputs this:
          string(14) "www.google.com"

          It's supposed to output a IPV4 address, no?

          Just wondering what your machine might be coughing up.

            Run through web server I get the same as you. Run from the CLI

            string(13) "74.125.39.105"
            

            Resolving hosts is broken for everything when PHP is run through the web server, not just for cUrl, and it works for everything when not run through web server: CLI execution of php functions such as this one or ping/tracert from terminal.

            Oh, and I did not. I stay as far away from configuration and administration as I can since there are people better suited for this than me. The dev server is running Darwin Kernel Version 9.8.0 (OSX), while test and prod is running Red Hat 5.6 (Tikanga)

              So these systems are both running PHP 5.3.3, correct? Could you also provide the following detail for each system?

              OS
              Apache Version
              cURL version

                I found a thread detailing this same problem and the poster apparently solved it by editing some file (rc.conf?) containing this line:

                DAEMONS=(syslog-ng @network @sshd @inadyn mysqld httpd @netfs @samba crond)
                

                Apparently Apache caches some DNS related information on startup. If the network daemons are not started before apache gets up and running, this information will not be properly cached. His solution was to force network to launch in the foreground.

                Restarting apache is apparently not enough to force the reload of that cached DNS info, however, doing this worked for me:

                sudo /usr/local/apache2/bin/apachectl stop
                sudo /usr/local/apache2/bin/apachectl start
                

                Your commands may have a slightly different path.

                Now if only I could determine how to get apache to start/stop properly only after the network is up. This being a mac (with screen saver and auto-sleep settings) the issue seems complicated. For now, a workaround is to stop apache and then start it again.

                  Nice! The stop/start worked for me as well, so I emailed a friend with good unix knowledge (but sadly not including OSX) about the last part and roughly got this answer

                  I do not know how OSX starts its services, but you could take an ugly approach and fix your immediate problem by stopping and starting the service in /etc/rc.local.

                  rc.local is supposed to be the last script run at startup (assuming Apple has not decided to disregard this file).
                  Startup scripts are run as root, so you won't need sudo. If /etc/rc.local does not exist, create it.

                  which apachectl should tell you the path to your apachectl file.

                  I havn't tried this myself yet but I suppose it should work even if it's ugly. The real solution would obviously include reading up on how to control services on OSX, which is trivial and left as an excersize for the reader (I always did find those remarks annoying in my maths books, but it's useful for the lazy writer 😉)
                  And it'd actually surprise me if it's trivial to someone without more intimate knowledge of unix operative systems, such as myself.

                    That doesn't sound particularly ugly to me. I wonder if it works when you sleep/wake up?

                    What's ugly is trying to replace the original PHP that comes on a Mac. Whenever I configure/make/make install PHP, it seems to end up in /usr/local/bin rather than /usr/bin so I have to type the full path. Trying to sort that one too. Today is get-all-the-debugging-setups-working day.

                    BTW, someone on the other forum I posted sent this link which helps sort out startup/login issues on OSX:
                    http://osxfaq.com/Tutorials/LearningCenter/HowTo/Startup/index.ws

                      Write a Reply...