Can you reproduce this problem on the command line as well? It might be worth trying that. Run your PHP script as follows:

USE_ZEND_ALLOC=0 XDEBUG_CONFIG="idekey=cegprakash" php -n -dzend_extension=/usr/lib/php/20151012/xdebug.so -dxdebug.auto_start=1 -dxdebug.remote_log="/usr/lib/php/xdebug-logs.log" your-simplest-script.php

And then check again what is in /usr/lib/php/xdebug-logs.log

Yes I get the same logs.

I also get the following message in command line

Xdebug requires Zend Engine API version 320151012.
The Zend Engine API version 320170718 which is installed, is newer.
Contact Derick Rethans at http://xdebug.org/docs/faq#api for a later version of Xdebug.

So I tried

SE_ZEND_ALLOC=0 XDEBUG_CONFIG="idekey=cegprakash" php -n -dzend_extension=/usr/lib/php/20170718/xdebug.so -dxdebug.auto_start=1 -dxdebug.remote_log="/usr/lib/php/xdebug-logs.log" info.php

and it just prints the same log

Log opened at 2019-01-23 10:49:30
I: Connecting to configured address/port: localhost:9000.
W: Creating socket for 'localhost:9000', poll success, but error: Operation now in progress (29).
E: Could not connect to client. :-(
Log closed at 2019-01-23 10:49:30

Just a note to say I'm seeing this precise issue with Xdebug 2.7.1 on an Ubuntu 18.04 Vagrant machine, which is being debugged by PHPStorm under Mojave.

The command run by PHPStorm was
[vagrant:///Users/kier/Sites/xf-sbp]:/usr/bin/php -dxdebug.remote_enable=1 -dxdebug.remote_mode=req -dxdebug.remote_port=9000 -dxdebug.remote_host=172.16.141.2 /var/www/public/xf/cmd.php

And the resulting log entry was as follows:
[3484] Log opened at 2019-07-23 12:28:57
[3484] I: Connecting to configured address/port: 172.16.141.2:9000.
[3484] W: Creating socket for '172.16.141.2:9000', poll success, but error: Operation now in progress (29).
[3484] E: Could not connect to client. :-(
[3484] Log closed at 2019-07-23 12:28:57

If I can run any other tests to help isolate the issue, please let me know.

Might be worth noting that the following from inside the Vagrant machine:

nc -vz 172.16.141.2 9000
nc: connect to 172.16.141.2 port 9000 (tcp) failed: Connection refused

@Kier — that sounds like a networking issue on your side. If Xdebug/PHP can't connect to the IDE, then it can't debug. Your "nc" call just proved that it can't connect, which means that PhpStorm is not listening on port 9000 on IP address 172.16.141.2. That looks like an internal Vagrant IP address, which is likely not shared through to PhpStorm. I'd recommend you put Vagrant's network into "Bridged" mode, instead of the (Default) NAT.

@derick This is starting to look like an issue with Vagrant, VMware Fusion or PHPStorm but I thought it would be useful to update this report anyway with my findings.

The virtual machine reports the following IP configuration:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.141.139 netmask 255.255.255.0 broadcast 172.16.141.255

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.33.10 netmask 255.255.255.0 broadcast 192.168.33.255

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0

Debugging PHP scripts running through Apache into Chrome is working flawlessly. The debug logs show that the connection is passing to 192.168.33.1, which is using the vmnet2 interface on the virtual machine (fig: net2.png).

[1307] Log opened at 2019-07-23 13:43:27
[1307] I: Checking remote connect back address.
[1307] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[1307] I: Checking header 'REMOTE_ADDR'.
[1307] I: Remote address found, connecting to 192.168.33.1:9000.
[1307] I: Connected to client. :-)

However, using the standard PHPStorm config, which is to 'Pass required configuration options through command line' (fig: config.png), it would appear that PHPStorm will instead attempt to connect through the first defined network interface, which is the 172.16.141.x address we see (fig: net1.png). Connection over port 9000, or any other port that I have tried, is refused. Using these options, the following debug command is run:

[vagrant:///Users/kier/Sites/xf-sbp]:/usr/bin/php -dxdebug.remote_enable=1 -dxdebug.remote_mode=req -dxdebug.remote_port=9000 -dxdebug.remote_host=172.16.141.2 /var/www/public/xf/cmd.php

Clearly, PHPStorm is connecting to the wrong IP for the virtual machine, but there doesn't appear to be a way to correct that, so instead it is necessary to disable that option to have PHPStorm send command-line configuration, and instead we must rely on Xdebug config itself. Setting xdebug.remote_host = 192.168.33.1 and disabling PHPStorm's "Pass required configuration options through command line" option allows debugging to work correctly.

[vagrant:///Users/kier/Sites/xf-sbp]:/usr/bin/php /var/www/public/xf/cmd.php

results in

[2276] Log opened at 2019-07-23 14:01:10
[2276] I: Checking remote connect back address.
[2276] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[2276] I: Checking header 'REMOTE_ADDR'.
[2276] W: Remote address not found, connecting to configured address/port: 192.168.33.1:9000. :-|
[2276] I: Connected to client. :-)

Hi Keir,

I would log a support question with PhpStorm, as in my opinion, they do this wrong. I fail to understand how they get that IP address in the first place, but that's something for them to investigate.

cheers,
Derick

Will do, @derick. Thanks for a great project in Xdebug.

I'm closing this issue, as so far, there is nothing that indicates that Xdebug is doing something wrong.

cheers,
Derick