PHP Versions Question posted in
You can find a list of all versions here.

Php versions – Visual Studio Extention PHP Debug not connecting

I have visual studio code 1.41.1 installed with PHP Debug Version – 1.13.0.

https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug

I am running PHP Lamp stack on Ubuntu, my PHP info is showing “xdebug
xdebug support enabled – Version 2.9.0”

My PHP.ini is configured as follows:

[XDebug]
zend_extension = /usr/lib/php/20170718/xdebug.so
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1
xdebug.remote_handler = dbgp
;xdebug.remote_host = 192.168.1.103
xdebug.remote_port=9000
xdebug.remote_log=/var/log/xdebug.log

My launch.json is as follows:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "hostname": "192.168.1.23"
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000,
            "hostname": "192.168.1.23"
        }
    ]
}

My Server is running on 192.168.1.23 and my ide is running on 192.168.1.103.

When I try to ‘Listen for XDebug’ or ‘Launch currently open script’
I get the following error:

Error: listen EADDRNOTAVAIL: address not available 192.168.1.23:9000
    at Server.setupListenHandle [as _listen2] (net.js:1209:19)
    at listenInCluster (net.js:1274:12)
    at doListen (net.js:1413:7)
    at processTicksAndRejections (internal/process/task_queues.js:84:9) {
  code: 'EADDRNOTAVAIL',
  errno: 'EADDRNOTAVAIL',
  syscall: 'listen',
  address: '192.168.1.23',
  port: 9000
}

I have tried to both setting xdebug.remote_connect_back to 0 and 1 and specifying the remote host IP explicitly with xdebug.remote_host = 192.168.1.103 or commenting it out too

The error triggers almost instantly in Visual Studio which would indicate that it is getting blocked locally.

Looking at my log file: xdebug.log I’m getting:

[2268] Log opened at 2020-01-08 12:39:09
[2268] I: Connecting to configured address/port: 192.168.1.103:9000.
[2268] E: Time-out connecting to client (Waited: 200 ms). :-(
[2268] Log closed at 2020-01-08 12:39:09

[2225] Log opened at 2020-01-08 13:09:37
[2225] I: Checking remote connect back address.
[2225] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[2225] I: Checking header 'REMOTE_ADDR'.
[2225] W: Remote address not found, connecting to configured address/port: localhost:9000. :$
[2225] W: Creating socket for 'localhost:9000', poll success, but error: Operation now in pr$
[2225] E: Could not connect to client. :-(
[2225] Log closed at 2020-01-08 13:09:37

The log file seems slow to write – I am not sure which event have been triggering the events in the log. I suspect It was accessing the webpage directly from my remote host rather than through Visual Studio Code.

I have also set my windows defender firewall to be open on port 9000.

Edits based on comments.
192.168.1.103 Is the IP address of the windows 10 machine running visual studio code. The machine is also running Version 6.0.8 r130520 (Qt5.6.2)and the IP address of the virtual machine is 192.168.1.23.

I have updated the timeout to 2000 ms.

I have observed, that if I shut the virtual machine down, VSC tries to connect and remaining trying to connect much longer. Whereas then the virtual machine is up, it errors instantly. Which would suggest that the virtual machine is blocking the port?

Finally – what triggers entry into xdebug.log. Would simply loading a PHP file on website trigger output the logger? The reason I ask is I can’t discernable trigger an error, but opening up the log file between time deltas, I.e. today vs last night, there have been various errors generated?

The machine and virtual machine are both secure behind router-based firewalls so this wouldn’t be external traffic.

The virtual machine is operating on the windows 10 client machine as expected. Just failing to connect the debugger. But PHP/MYSQL/ APACHE are all running correctly.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    The problem was related to the firewall blocking incoming connections. It was solved with the following steps for me:

    Install UFW - 

    sudo apt-get install ufw
sudo ufw enable
sudo ufw allow 9000/tcp

    In my Php.ini I use the following settings:

    [dDebug]
zend_extension = /usr/lib/php/20190902/xdebug.so
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1
xdebug.remote_port=9000

    Finally, my launch Json has the following:

    {
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "pathMappings": {
                "/var/www/html/YourApp": "${workspaceRoot}/"
              }

        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

    The JSON is assuming that work-space is pointing to the root of the source data and it's not tucked away inside a sub-folder.

    Finally, you will want to add UFW rules to access your web server remotely, as these were not present by default in UFW after installing

    sudo ufw app list
sudo ufw allow 'Apache Full'

    I also added other rules from my app list using that method.

    I hope this helps someone like me who was struggling to connect to xDebug on a newly spun up Ubuntu 18.04.4 VM.


  2. 0

    It looks like something else is already listening on port 9000, and hence, VS can’t open the same port for listening as well. It is likely that this is PHP-FPM.

    To work around this, set the following instead in php.ini:

    xdebug.remote_port=9003

    And change the VS config (twice) to this same port:

    "port": 9003,
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search