Xdebug does not connect #1083

bschnitz · 2024-10-10T14:10:53Z

bschnitz
Oct 10, 2024

What happened?

I'm trying to configure xdebug with frankenphp. I have a rather minimal setting for xdebug, which essentially consists of setting xdebug.start_with_request to yes (but I also tested some other configuration options) and setting the XDEBUG_MODE environment variable to develop. The phpinfo() output indicates, that xdebug should work as expected and would connect to port 9003 (standard as of xdebug 3). So I used the dbgpClient command line client to test debugging by invoking it from within and from outside of the docker container without arguments, such that it would listen on port 9003. After that I opened a page on the server in the browser.

I would expect now:
dbgpClient shows that a connection was made.

But actually:
dbgpClient shows no output.

I also tried other IDEs, like neovim and VSCode, with an /app to {$workspace} mapping and by setting some breakpoints. But there was no connection established either.

Build Type

Docker (Debian Bookworm)

Worker Mode

Yes

Operating System

GNU/Linux

CPU Architecture

x86_64

PHP configuration

Relevant log output

No response

Answered by withinboredom

Oct 10, 2024

There is no need to use the magic hostname or do that workaround in docker-compose, you can just set the xdebug host to xdebug://gateway.

I see you are running in worker mode. That means these are long running scripts, so the debugging session started with the worker, not your request. That can be worked around by calling xdebug_connect_to_client() somewhere in your code.

This is the relevant part:

Normally, Xdebug tries to start a debugging session at the start of the request. If a debugging client is not listening at that point, then Xdebug does not try to re-establish a connection during the remainder of the request.

In the situation where one long running PHP process handles multip…

View full answer

withinboredom · 2024-10-10T16:23:29Z

withinboredom
Oct 10, 2024
Collaborator

This sounds like a configuration issue with xdebug. Docker containers do not typically see the real ip address (you should see this in the xdebug logs). Please see #1037 (reply in thread) which might have the relevant information you are looking for.

3 replies

bschnitz Oct 10, 2024
Author

@withinboredom Hey, thank You for the reply and the suggestions :D.

I have to admit, that I'm a bit lost here. I'm not sure if I understand, what You mean by "Docker containers do not typically see the real ip address". I know, that docker containers exist in the docker network and have have an ip there, so if a connection from the host is made, they will not see it as a connection from localhost, but from another ip in that network. So xdebug needs to know this ip. In windows, there is already a mapping to the host.docker.internal alias, in Linux this does not exist out of the box. So as far as I know, this can be resolved e.g. when using docker compose by adding the following section to the compose.yml:

    extra_hosts:
      # Ensure that host.docker.internal is correctly defined on Linux
      - host.docker.internal:host-gateway

Now of course xdebug needs to now, that this is the host to connect to, which can be set using xdebug.client_host = host.docker.internal.

Normally that worked for me for other servers I used to work with (nginx, apache) and I never had to configure my IDE in any special way (except for the mapping of the workspace path).

However, this time it didn't, this is also why I tried using dbgpClient from within the docker container to rule out any wrong ip-adress mapping, since inside the container xdebug should be able to communicate to localhost without problems, wouldn't it? Of course I removed the xdebug.client_host = host.docker.internal prior to testing that.

But I have a feeling, that I may a serious misunderstanding of the internals of docker or maybe caddy here?

Oh, and also thank You for moving this to Q & A, I didn't see that there was something like this here.

Edit again. Since You hinted the xdebug logs. I now looked into them, but I didn't see anything special. This is all (repeating again and again):

[132978333039296] Log opened at 2024-10-10 16:47:56.506009
[132978333039296] [Config] INFO: Control socket set up succesfully: '@xdebug-ctrl.132978333039296'
[132978333039296] Log closed at 2024-10-10 16:47:56.809912

withinboredom Oct 10, 2024
Collaborator

There is no need to use the magic hostname or do that workaround in docker-compose, you can just set the xdebug host to xdebug://gateway.

I see you are running in worker mode. That means these are long running scripts, so the debugging session started with the worker, not your request. That can be worked around by calling xdebug_connect_to_client() somewhere in your code.

This is the relevant part:

Normally, Xdebug tries to start a debugging session at the start of the request. If a debugging client is not listening at that point, then Xdebug does not try to re-establish a connection during the remainder of the request.

In the situation where one long running PHP process handles multiple tasks, perhaps from a queue, calling xdebug_connect_to_client() can then be used to re-try to establish a connection for a specific worker job.

Answer selected by bschnitz

bschnitz Oct 11, 2024
Author

Hey, great, using xdebug_connect_to_client() worked! Also I removed the docker-compose workaround and it still worked. Seems like the debuggers of neovim and vscode already use xdebug://gateway automatically.

Thank You for your help!!!

Oh and I also forgot to add debug to the xdebug.mode setting.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Xdebug does not connect #1083

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Select a reply

Uh oh!

Uh oh!

Xdebug does not connect #1083

Uh oh!

bschnitz Oct 10, 2024

What happened?

Build Type

Worker Mode

Operating System

CPU Architecture

PHP configuration

Relevant log output

Replies: 1 comment · 3 replies

Uh oh!

withinboredom Oct 10, 2024 Collaborator

Uh oh!

Uh oh!

bschnitz Oct 10, 2024 Author

Uh oh!

withinboredom Oct 10, 2024 Collaborator

Uh oh!

Uh oh!

bschnitz Oct 11, 2024 Author

bschnitz
Oct 10, 2024

Replies: 1 comment 3 replies

withinboredom
Oct 10, 2024
Collaborator

bschnitz Oct 10, 2024
Author

withinboredom Oct 10, 2024
Collaborator

bschnitz Oct 11, 2024
Author