Xdebug does not work - vscode under linux


This message is because I am seeking for help, I am searching on the web, but any source found until now has not worked in order to get xdebug working.

this is the main documentation that I have been follow Docker on Linux: Xdebug for Visual Studio Code — Devilbox 1.0 documentation. Also I used this another one (but seems suggest a deprecated launch.json values) Enable Xdebug — devilbox documentation

I am using php7.4. I have to say that on .env I have changed the HOST_PATH_HTTPD_DATADIR days ago, I don’t know if this is the problem. (Anyway I was traying to enable xdebug before the change to the .env file and was not possible to have xdebug running).

There is no error on the xdebug error log.

this is the xdebug.ini file:

; Defaults

; The Linux way

; idekey value is specific to Visual Studio Code

; Optional: Set to true to always auto-start xdebug

This is the launch.json vscode:

"configurations": [
      "name": "DevilBox / Drupal 9",
      "type": "php",
      "request": "launch",
      "port": 9000,
      "pathMappings": {
        "/shared/httpd/drupal9/www": "/home/userxyz/docker-drupal9/www/drupal9/www"


I have a progress with this case, I mean, still xdebug is not working on my Devilbox v1.9.2 (2021-06-04) (was easy on Lando but I want to have running on Devilbox). According my findings, the problem could be related that Devilbox that I am using comes with Xdebug 3, and the documentation is in some places outdated regarding that.

Here a couple of resources related:

Confusing XDBUG documentation · Issue #381 · cytopia/devilbox · GitHub (last comment)
Xdebug 3.0: How to configure xdebug 3.0 for Magento docker (Devilbox)

First I follow the Linkedin source instructions, unfortunately was not working for me, so I have added the service:php: port portion described at the github source for devilbox\docker-compose.override.yml file described at github resource.

Now I have the issue related with port conflict, I think that is a good progress. In my case the address that gives a connection (I mean, it works! (¿did it?) but with the conflict) is docker.for.lin.host.internal. That docker.for.lin.host.internal can be found in .env.

Here the xdebug.ini located at cfg/php-ini-7.4/ (7.4 in my case)


xdebug.show_error_trace = 1

I hope this info will be useful to others with same issue (Unfortunately I can not continue checking this issue right now, I hope to have time soon).

I have a similar problem, but got this error on xdebug.log:

[2142] Log opened at 2021-09-15 19:53:11.897849
[2142] [Step Debug] INFO: Connecting to configured address/port: localhost:9000.
[2142] [Step Debug] INFO: Connected to debugging client: localhost:9000 (through xdebug.client_host/xdebug.client_port). :-)
[2142] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/default/htdocs/info_xdebug.php" language="PHP" xdebug:language_version="7.4.20" protocol_version="1.0" appid="2142" idekey="VSCODE"><engine version="3.0.4"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2021 by Derick Rethans]]></copyright></init>

[2142] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>

[2142] [Step Debug] WARN: 2021-09-15 19:53:11.912830: There was a problem sending 179 bytes on socket 8: Broken pipe.
[2142] Log closed at 2021-09-15 19:53:11.912965

So I tried - as you did - to override the port from 9000 to 9003, resulting in a server temporarily unavailable error…

version: '2.3'


  # ------------------------------------------------------------
  # Web Server
  # ------------------------------------------------------------

      ## PHP-FPM Remote Server
      - PHP_FPM_SERVER_PORT=9003

Xdebug is working with liveserver using php/xdebug which is installed on my ubuntu OS. Using the devilbox environment, xdebug is not working. Tried out several configurations, as documentation under devilbox’ site is not useful for xdebug 3… I suppose it has to do with the docker-compose.yml entry for php port 9000, which is not appropriate for xdebug 3 in my knowledge.

As I learned from derick, founder of the vscode debug extension for xdebug, the port 9000 should be left on php_FPM. Xdebug should be set to 9003. Doing so, I get

[1810] Log opened at 2021-09-16 09:43:24.704780
[1810] [Step Debug] INFO: Connecting to configured address/port: localhost:9003.
[1810] [Step Debug] WARN: Creating socket for 'localhost:9003', poll success, but error: Operation now in progress (29).
[1810] [Step Debug] WARN: Creating socket for 'localhost:9003', connect: Cannot assign requested address.
[1810] [Step Debug] ERR: Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port) :-(

phpinfo() leads me to a help paragraph saying this:

**Check whether your debugging client is listening on the indicated address and port. On Linux and OSX, you can use netstat -a -n | grep LISTEN to check. 
Change xdebug.client_host and/or xdebug.client_port to the right address/hostname and port of where the debugging client is listening. **

listening to *.9003

" this seams to be correct

→ Change xdebug.client_host → this option is not available in php.ini…**

So how to change xdebug.client_host? And to which address?

I tried this in my xdebug.ini on devilbox, and its working!! Typing xdebug. does not show me this option, maybe a mistake in intellisense or whatever is there in the background? Thats why I did not try this before.

Not sure why to take just this address anf if this address will be always the same?

Hello Ernestopheles, thanks for your comments and ideas, give me the push forward to follow.
I removed xdebug.ini custom changes added to cfg / php-ini-7.4 directory in devilbox, then stop / run again devilbox and according php info xdebug is using address (maybe xdebug was affected with starting changes to the configuration, anyway , the expected address appears). Then I enabled xdebug on VSCode again but this time using the common 9000 (and not the 9003 expected by new xdebug version), and the orange bar related to connection made showed up now on VScode !!.

This is a good signal, connection made!

Then I assigned some breakpoints but no breakpoints were achieved. But due connection was made, I thought that the problem is focused on vscode side. I checked launch.json, and on the directories mapped, I found that is not required to map the directory that is required by the vhost (the required ‘htdocs’ inside every virtual host), so I removed it from the “pathMappings” in launch.json and voila! breakpoints are mapped and working right now.

I am trying to create another fresh Devilbox to test from zero those findings and post an update but appears the error “ERROR: Pool overlaps with other one on this address space”. This is other problem not related with this thread, but I hope on a new fresh Devilbox test again.

Hello cigotete

not sure if i can follow your description. But I solved the problem for me, you will find the configuration for linux, xdebug 3 and vscode here: Update vscode.rst by Ernestopheles · Pull Request #836 · cytopia/devilbox · GitHub

Hope this will help and thanks for your help, too


I have created another Devilbox from zero. Checking by default the Xdebug on devilbox comes with address ‘localhost’ (and I have created the respective launch.json in Vscode to test xdebug and xdebug is not working as is expected).

So following settings to the xdebug.ini were located at cfg/php-ini-X.X/ (7.4 in my case), stop/up devilbox again, and xdebug settings shows new IP. Test again with Vscode and works xdebug.

xdebug.show_error_trace = 1

Xdebug breakpoints are catched ok.

Hi @Ernestopheles thanks for your last message. In my case Xdebug is working now too. Is weird because in your case works in port 9003 and in my case works with port 9000.

If you are using xdebug 3 I think it will be best to use the actual configuration as describes above. See also: