0

I have a very simple snippet of code:

<?php
    $fp = fopen(dirname(__FILE__).'/errorlog.txt', 'w');
    fwrite($fp, "writing works..\n");
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, "http://10.0.0.1/url");
    curl_setopt($ch, CURLOPT_VERBOSE, 1);
    curl_setopt($ch, CURLOPT_STDERR, $fp);
    print_r(curl_exec($ch));
    print_r(curl_errno($ch));
    print_r(curl_getinfo($ch));
    print_r(curl_version());
    curl_close($ch);
    fclose($fp);
?>

Which works fine in general, but it is currently broken in a particular environment I'm using. curl_errno returns 2, i.e. CURLE_FAILED_INIT.

I'm trying to investigate whether there are system issues here, but I would like to know if there is some way I can debug code-wise what's the issue.

Answers like the ones in this question do not yield any output (file errorlog.txt is simple found empty.. which is expected I guess since libcurl can't even initialize).

The output of curl_getinfo() is just useless since it never gets to do the request. This is the curl_version output:

[version_number] => 466176
[age] => 3
[features] => 558781
[ssl_version_number] => 0
[version] => 7.29.0
[host] => x86_64-redhat-linux-gnu
[ssl_version] => NSS/3.28.4
[libz_version] => 1.2.7
[protocols] => Array
    (
        [0] => dict
        [1] => file
        [2] => ftp
        [3] => ftps
        [4] => gopher
        [5] => http
        [6] => https
        [7] => imap
        [8] => imaps
        [9] => ldap
        [10] => ldaps
        [11] => pop3
        [12] => pop3s
        [13] => rtsp
        [14] => scp
        [15] => sftp
        [16] => smtp
        [17] => smtps
        [18] => telnet
        [19] => tftp
    )

Anyone has any pointers?

Thanks

JoeSlav
  • 4,479
  • 4
  • 31
  • 50
  • 1
    Possible duplicate of [PHP - Debugging Curl](https://stackoverflow.com/questions/3757071/php-debugging-curl) – ArtisticPhoenix Mar 04 '19 at 16:31
  • Unfortunately those do not help in my case. – JoeSlav Mar 04 '19 at 16:38
  • Please see the error explained: CURLE_FAILED_INIT (2) - Very early initialization code failed. This is likely to be an internal error or problem, or a resource problem where something fundamental couldn't get done at init time. [source](https://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLEFAILEDINIT) - [Next step I would suggest is to get the version info (see it at half of the question)](https://stackoverflow.com/q/49658719/367456) and find out where the earliest point is the error is given (e.g. does it happen on init already?, have you tried `curl_init()` with the URL?) – hakre Mar 04 '19 at 17:04
  • Err, just seeing you do the check for the curl version already, I think you should more of the the debugging information to your question as it looks like it's kind of specific. This should also make more clear in which sense it is different to the existing Q&A material here on site. I must admit, this error looks rather specific. – hakre Mar 04 '19 at 17:07
  • Added some info above in the question. Thanks for jumping on this, much appreciated. Also see more info in the SF question. I really don't know how to troubleshoot anymore. I'm trying to copy-paste conf files from another server where this works.. on the other server the curl.so is the same as on this one where it's broken.. :/ – JoeSlav Mar 04 '19 at 17:12
  • 1
    If you really feel like doing lowlevel debugging, start with `strace`, then work your way up to `gdb` with php-cli. – mario Mar 04 '19 at 17:12
  • strace is a good hint by mario. I had success with that in the past on system configuration issues, it's just that I didn't think about it most likely as I don't use it often. /E: I don't think it's configuration files. – hakre Mar 04 '19 at 17:14
  • @mario Thankkkk youuu!!! you gave me my first breakthrough in 4 days.. I just discovered that if I run the php file with cli, it works..... I feel one step closer to finding the mistery... – JoeSlav Mar 04 '19 at 17:16
  • 1
    Have you reloaded / restarted the webserver (httpd) after upgrade? And which PHP SAPI are you using? – hakre Mar 04 '19 at 17:17
  • rebooted the machine, and also rebooted countless times httpd and fpm. I think it might be a permission issue – JoeSlav Mar 04 '19 at 17:21
  • With fpm it sometimes can happen it uses the old version. Is the old version completely removed from the system? This can help to shield against such effects (httpd / fpm won't then mabye properly start, so just saying). Machine reboot should not be necessary at all, I normally try to prevent such grave steps as it is for me that I admit I'm not very creative any longer and I can only pull out the big hammer... ;) – hakre Mar 04 '19 at 17:31
  • The history was: installed 5.4, installed 5.6, removed 5.4 & 5.6, installed 5.6 .. during the coexistence the 5.4 was working while 5.6 wasn't. I was told it was removed fine. Trying to understand now why it works with CLI and why it doesn't with apache. both instances use the same .ini files (as per phpinfo()). – JoeSlav Mar 04 '19 at 18:05
  • @mario, your answer is the correct one for this question, if you post an answer i'll accept it. At the end of the day we restored the VM to pre php 5.4 and 5.6 and reinstalled only 5.6 and it worked. we will never know............ – JoeSlav Mar 06 '19 at 11:57

0 Answers0