Docker stops working after php debugger is stopped

[gyosko]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• [] I have uploaded Diagnostics
• Diagnostics ID: Diagnostic is not being generated

Expected behavior

After I stop the Visual Studio "Listen for Xdebug" debugger configuration, Docker should keep working as usual.

Actual behavior

Docker stops working after Visual Studio debugger is stopped.

Information

• macOS Version: 12.3
• Intel chip or Apple chip: Intel
• Docker Desktop Version: 4.6.0 (75818)

Output of /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check

Starting diagnostics

[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0031: does the Docker API work?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0011: are the LinuxKit services running?
[FAIL] DD0016: is the LinuxKit VM running? vm is not running: vm has not started
[PASS] DD0001: is the application running?
[PASS] DD0018: does the host support virtualization?
[FAIL] DD0017: can a VM be started? vm has not started: vm has not started
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0007: is the backend responding?
[PASS] DD0014: are the backend processes running?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[PASS] DD0012: is the VM networking working?
[PASS] DD0032: do Docker networks overlap with host IPs?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0019: is the com.docker.vmnetd process responding?
[PASS] DD0033: does the host have Internet access?

Please investigate the following 1 issue:

1 : The test: can a VM be started?
    Failed with: vm has not started: vm has not started

The Docker engine runs inside a Linux VM. Therefore we must be able to start Virtual Machines.

Steps to reproduce the behavior

1. Start any lamp application with docker-compose
2. Start Visual Studio PHP Debugger
3. Debug request
4. Stop Visual Studio PHP Debugger

[malis42]

I believe I have the same problem, although I used intelliJ IDE for debugging with xdebug and PHP 7.4. After downgrading to Docker Desktop version 4.4.2 problem disappeared.

[gyosko]

Same here, I downgraded to 4.5 and the problem disappeared.

[mrgyf1]

Same problem solved with downgrade to 4.5 (Apple Chip)

[luancschmitz]

same problem here. The website gives error 502 bad gateway.
Downgrading to version 4.5.0 resolved the issue.
(Apple Silicon M1)

[ubermaniac]

Same issue here as well with M1 and Intel. Downgrading to 4.5.0 works fine.

[darkniki]

Same issue here as well with m1 and intel, in phpstorm, disabling chrome xdebug helper solves this problem
upd: 4.6.1 doesn't fix this

[Zekvyrin]

There is a new desktop version 4.6.1 that fixes this #6233

Tests stopped initiating from me today but they started again after the upgrade. So maybe it is fixed?

[gyosko]

@Zekvyrin it looks like #6233 solves the diagnostic tools, but it does not fix this issue

[froboy]

Confirming the issue is still present in 4.6.1. I'm able to recreate the issue with PHPStorm's debugger on an M1. Restarting my containers did NOT resolve the problem, but restarting all of Docker did.

[bobooon]

Same issue here on 4.6.0 and 4.6.1. Downgrading to 4.5.0 resolved the issue.

[froboy]

Running diagnostics while the system is in this broken state doesn't throw any errors:

❯ /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check
Starting diagnostics

[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0031: does the Docker API work?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0001: is the application running?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0017: can a VM be started?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0007: is the backend responding?
[PASS] DD0014: are the backend processes running?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[PASS] DD0012: is the VM networking working?
[PASS] DD0032: do Docker networks overlap with host IPs?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0019: is the com.docker.vmnetd process responding?
[PASS] DD0033: does the host have Internet access?
No fatal errors detected.

Logs for the containers didn't contain any useful errors... hitting my site from the browser or even curl -I ... just hung indefinitely.

[mglaman]

What port is Xdebug using? Is it still 9000 or 9003? I have mine on 9003 and didn't experience issues. 9003 is new for Xdebug3 but some may still be on 9000

[rfay]

Diagnostics: 165EF212-DB99-4FE1-90A4-E516A309B23F/20220323170553

This is with ddev v1.19.1, which listens on port 9003. When the OP says "docker doesn't work" after turning off the xdebug listener, that seems to mean that HTTP requests are no longer fulfilled, things just hang. docker ps and such still work.

1. ddev debug test will create a trivial php project.
2. cd into the project. ddev list will show you where it is
3. curl -I http://tryddevproject-31649.ddev.site in my case (your number will be different). It will succeed with a 200.
4. ddev xdebug on
5. nc -l 9003 to pretend to be a host-side xdebug listener
6. curl -I http://tryddevproject-31649.ddev.site - you'll see the 200 again.
7. You'll see the xdebug connection, 472<?xml version="1.0" encoding="iso-8859-1"?> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/html/index.php" language="PHP" xdebug:language_version="7.4.28" protocol_version="1.0" appid="1865"><engine version="3.1.2"><![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>
8. Kill (ctrl-c) the nc process
9. Now any new http request (curl -I http://tryddevproject-31649.ddev.site ) hangs.

Note that this seems to be fixed with ddev xdebug off, which stops php from attempting to connect. Perhaps only one connection to a given port is being allowed? (Or else I'm not actually reproducing)

But if everybody could see if turning off xdebug on the php side solves it, that may be of some interest.