5

After upgrading Docker to 4.6.0 on OSX 12.3 I've had a bit of an odd issue when I stop the xdebug listening client in PHPStorm, it seems that subsequent requests always times out because docker is reporting that host.docker.internal has port 9003 open when it's actually closed so the app always waits for the xdebug client.

I installed nmap on my webapp php container and host to test. If I run "nmap -p 9003 localhost" with the debug client running on my host I can see it open, after turning it off in PHPstorm the same scan shows that it's closed however running "nmap -p 9003 host.docker.internal" inside the container reports that it's still open. If I open other services on my host too it seems that ports start showing as open on the docker internal network however never report as closed after shutting them down on the host.

I upgraded to Docker 4.6.1 but the problem still persists.

Any advice would be appreciated.

gkr34kg
  • 91
  • 4
  • 2
    I have the same problem, with Xdebug+VSCode, now to continue work I have to keep Xdebug listening all the time. Or restarting Docker Desktop helps to fix this (until I start another debugging session). – Viperet Mar 31 '22 at 09:28
  • Our entire team has the same issue, the breakpoints get caught fine but when you stop the debugger the service completely hangs. The only thing you can do is restart the docker desktop service completely. @Viperet and we're also running 4.6.1 – Andy Davies Mar 31 '22 at 19:48
  • @Viperet did you find a solution? We're still experiencing it – Andy Davies Apr 06 '22 at 09:54
  • @AndyDavies I just have a script now which restarts the php container without the xdebug module loaded. That way it doesn't hang trying to connect to an Xdebug client. https://carstenwindler.de/php/enable-xdebug-on-demand-in-your-local-docker-environment/ . Not great but at least it's less annoying than restarting docker entirely. – gkr34kg Apr 06 '22 at 17:04
  • I've tried Docker 4.7 (just released) still broken! :-( – Andy Davies Apr 08 '22 at 15:02
  • 1
    Same issue here, the debugger on the host, the listening port seems to never be released (but it is) https://stackoverflow.com/q/71797035/972966 – JazzCat Apr 10 '22 at 11:51
  • @AndyDavies no solution yet, found a temporary workaround, added as an answer. – Viperet Apr 13 '22 at 13:17
  • 2
    FYI downgrading to Docker 4.5.0 resolved the issue for me. Link https://docs.docker.com/desktop/mac/release-notes/#docker-desktop-450 – Viperet Apr 15 '22 at 07:21
  • 1
    Tried 4.7.1 still broken – Andy Davies Apr 19 '22 at 13:35
  • 2
    Docker ticket: https://github.com/docker/for-mac/issues/6247 – LazyOne Apr 20 '22 at 15:53

2 Answers2

3

This has been fixed in Docker 4.8.1 https://docs.docker.com/desktop/mac/release-notes/

gkr34kg
  • 91
  • 4
1

UPDATE: Downgrading to Docker 4.5.0 resolved the issue.

This doesn't solve the problem, just helps to avoid restarting Docker while we are waiting for the fix. Make changes in xdebug.ini:

xdebug.start_with_request=trigger
xdebug.idekey=VSCODE

This tells XDebug to connect to debugger only if "trigger" is present in the HTTP request.

Now, install Chrome extension Xdebug helper, it's old but still works. Open extensions settings (chrome-extension://eadndfjplgieldjbigjakmdgkmoaaaoc/options.html) and set IDE key to "Other" "VSCODE".

Xdebug helper settings

Now, when you want to debug, you enable debugging in VSCode and also enable debugging in Chrome using that extension:

Enabling debugging in Xdebug helper

When you are done debugging - choose "Disable" in the extension, and PHP won't try to connect to your debugger, even if the port is still open. How it works - extension just sends cookie XDEBUG_SESSION=VSCODE with each request, and XDebug connects to the debugger only when this cookie is present.

P.S. You can replace VSCODE with IDE key that your IDE uses, or just any string.

Viperet
  • 1,355
  • 2
  • 8
  • 9