Unix socket not working and no xdebug.log

[jcvanhalle-ec]

Hello,
I can't get unix socket to work.

PHP version: 7.4.28
Xdebug version: 3.0.2
VS Code extension version: 1.26.1

Your launch.json:

        {
            "name": "Listen for Xdebug socket",
            "type": "php",
            "log": true,
            "request": "launch",
            "hostname": "unix:///tmp/xdebug.sock"
        }

Xdebug php.ini config:

zend_extension=xdebug.so
xdebug.mode=debug
xdebug.client_host=unix:///tmp/xdebug.sock
;xdebug.discover_client_host = true
xdebug.start_with_request=yes

xdebug.log=/tmp/xdebug.log
xdebug.log_level=7

Xdebug logfile (from setting xdebug.log in php.ini):
VS Code extension logfile (from setting "log": true in launch.json):

Listening on '/tmp/xdebug.sock'
<- launchResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 2,
  command: 'launch',
  success: true
}
<- initializedEvent
InitializedEvent { seq: 0, type: 'event', event: 'initialized' }
-> setBreakpointsRequest
{
  command: 'setBreakpoints',
  arguments: {
    source: { name: 'test.php', path: '/var/www/html/test.php' },
    lines: [ 3, 4, 5, 6 ],
    breakpoints: [ { line: 3 }, { line: 4 }, { line: 5 }, { line: 6 } ],
    sourceModified: false
  },
  type: 'request',
  seq: 3
}
<- setBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 3,
  command: 'setBreakpoints',
  success: true,
  body: {
    breakpoints: [
      {
        verified: true,
        line: 3,
        source: { name: 'test.php', path: '/var/www/html/test.php' },
        id: 1
      },
      {
        verified: true,
        line: 4,
        source: { name: 'test.php', path: '/var/www/html/test.php' },
        id: 2
      },
      {
        verified: true,
        line: 5,
        source: { name: 'test.php', path: '/var/www/html/test.php' },
        id: 3
      },
      {
        verified: true,
        line: 6,
        source: { name: 'test.php', path: '/var/www/html/test.php' },
        id: 4
      }
    ]
  }
}
-> setFunctionBreakpointsRequest
{
  command: 'setFunctionBreakpoints',
  arguments: { breakpoints: [] },
  type: 'request',
  seq: 4
}
<- setFunctionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 4,
  command: 'setFunctionBreakpoints',
  success: true,
  body: { breakpoints: [] }
}
-> setExceptionBreakpointsRequest
{
  command: 'setExceptionBreakpoints',
  arguments: { filters: [] },
  type: 'request',
  seq: 5
}
<- setExceptionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 5,
  command: 'setExceptionBreakpoints',
  success: true,
  body: { breakpoints: [] }
}
-> configurationDoneRequest
{ command: 'configurationDone', type: 'request', seq: 6 }
<- configurationDoneResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 6,
  command: 'configurationDone',
  success: true
}
-> threadsRequest
{ command: 'threads', type: 'request', seq: 7 }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 7,
  command: 'threads',
  success: true,
  body: { threads: [] }
}

Code snippet to reproduce:

<?php

$var = 9;
$add = 3;
$sum = $add + $var;
echo $var;

I run vs code with the configuration above on a vanilla apache2/php/debian11.

Steps to reproduce

1. Before running the debugger I delete any dangling socket left from a previous attempt (sudo rm /tmp/xdebug.sock)
2. I start debugging the php script, located in /var/www/html on Debian 11, launch.json is in /var/www/html/.vscode
   a. I chown the socket created by the extension at step 2 so it can be read/write by the webserver chown 33:33 /tmp/xdebug.sock.
   b. I leave the socket as it is created by the extension
3. I visit http://localhost/test.php with a web browser

Vs-code should then pick up and start the debugging process but nothing happens and xdebug.log is empty and not created. It's like xdebug didn't start server-side but everything works as expected if I swap the configuration with:

        {
            "name": "Listen for Xdebug classic",
            "type": "php",
            "log": true,
            "request": "launch",
            "port" : 9003
        }

zend_extension=xdebug.so
xdebug.mode=debug
xdebug.discover_client_host = true
xdebug.start_with_request=yes

xdebug.log=/tmp/xdebug.log
xdebug.log_level=7

Am I forgetting something in the configuration (xdebug.ini or launch.json) or am I misunderstanding how the socket is supposed to work ?

Why do I chown the socket ?
Actually my goal is to run the debugger from the host machine with PHP behind a reverse proxy both in their own container on the same docker network isolated from the host but so far it's not working either (but at least xdebug output some log) so I am trying to get the socket right first before trying further with the docker stack.

[zobo]

Hi.
Interesting, that it works with TCP (port 9003) but not with unix sockets. Since there is no xdebug.log, I suggest you add xdebug_info() to the end of the script and try again. There should be a lot of info about what is going on, also a short log if the debugger is trying to connect - and where to.

Also, this comes to mind from Xdebug documentation:

Warning: Many Linux distributions now use systemd, which implements private tmp directories. This means that when PHP is run through a web server or as PHP-FPM, the /tmp directory is prefixed with something akin to: /tmp/systemd-private-ea3cfa882b4e478993e1994033fc5feb-apache.service-FfWZRg

Regarding your docker issues. This is usually a problem one has to understand. If you are running VSCode on the host then your dockerized PHP process must connect to it. Since it is on a different network, it cannot use the default xdebug.client_host=localhost but rather the IP that you see on the docker0 interface on your host.

Also, thank you for the chmod heads up, that is something that should be configurable...

[jcvanhalle-ec]

Hi zobo,

Also, this comes to mind from Xdebug documentation:

Warning: Many Linux distributions now use systemd, which implements private tmp directories. This means that when PHP is run through a web server or as PHP-FPM, the /tmp directory is prefixed with something akin to: /tmp/systemd-private-ea3cfa882b4e478993e1994033fc5feb-apache.service-FfWZRg

Aha, yes ! There actually was some output: the xdebug.log is indeed located in a prefixed systemd-private-sthg directory:

[242302] Log opened at 2022-05-16 07:57:44.079990
[242302] [Step Debug] INFO: Connecting to configured address/port: unix:///tmp/xdebug.sock:9003.
[242302] [Step Debug] WARN: Creating socket for 'unix:///tmp/xdebug.sock', connect: No such file or directory.
[242302] [Step Debug] ERR: Could not connect to debugging client. Tried: unix:///tmp/xdebug.sock:9003 (through xdebug.client_host/xdebug.client_port) :-(
[242302] Log closed at 2022-05-16 07:57:44.081008

I created a directory somewhere else and (/mytemp) and launch.json and xdebug.ini both point to that folder for the socket and the debugger works. Thanks !

It's still required to chmod the socket (777) (chown also works) so xdebug (which is run by www-data) can manipulate it.

Can the socket be created with those rights (777 or 747) ? That'd save a step.

Regarding the docker issue: I am also trying to use dbgpproxy and php-dbgpproxy but since my whole stack is running in isolated mode behind a reverse proxy I am running into other different issues.

I can now focus on getting the socket working with my docker stack.

Edit: and now it works with docker, under the same principle.

Edit 2: I temporarily solved the permissions issue with a systemd unit that updates the socket permission automatically.

[plokko]

Similar problem here:

Php Debug v1.34.0
Running on devcontainer (WSL2)

Launch.json

        {
            "name": "XDebug",
            "type": "php",
            "request": "launch",
            "hostname": "unix:///tmp/xdebug.sock"
        },

Debug console:

[Error: getaddrinfo ENOTFOUND unix:///tmp/xdebug.sock
	at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26)] {
  errno: -3008,
  code: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'unix:///tmp/xdebug.sock'
}

[zobo]

Interesting. Let me check on this.

[zobo]

@plokko This is very strange. It looks like the unix:// would not be truncated before server listen gets invoked. Do you perhaps have some other extension installed that also registers a PHP debugger?

[zobo]

I went back and retried your config on my Linux VM and it works. Try to run the command "Developer: Show Running Extensions" from the command palette and try to find extensions that might conflict and disable them to see if this is the case.

[plokko]

@plokko This is very strange. It looks like the unix:// would not be truncated before server listen gets invoked. Do you perhaps have some other extension installed that also registers a PHP debugger?

i should have none conflicting and it's easy to check as i do list all extension on devcontainer config file:

  "extensions": [
    "eamodio.gitlens",
    "mhutchie.git-graph",
    "onecentlin.laravel-extension-pack",
    "vue.volar",
    "sdras.vue-vscode-snippets",
    "devsense.phptools-vscode",
    "ormulahendry.auto-rename-tag",
    "redhat.vscode-yaml",
    "xdebug.php-debug",
    "tabnine.tabnine-vscode",
    "christian-kohler.path-intellisense"
  ],

[zobo]

Actually devsense.phptools-vscode also contains a PHP debugger that is similar but slightly different than this official Xdebug extension. There is currently no way that these two extensions can co-exist and due to the fact that this extension name is xdebug.. and that one is devs... the second takes precedence. Try to disable PHP tools and try again.

Here is a relevant issue filed with Devsense: DEVSENSE/phptools-docs#355

[plokko]

Actually devsense.phptools-vscode also contains a PHP debugger that is similar but slightly different than this official Xdebug extension. There is currently no way that these two extensions can co-exist and due to the fact that this extension name is xdebug.. and that one is devs... the second takes precedence. Try to disable PHP tools and try again.

Here is a relevant issue filed with Devsense: DEVSENSE/phptools-docs#355

You were right,if i disable it works!
I didn't take in consderation that i may had other extension with XDebug!