I've encountered a weird problem that seems to have either started appearing when the Xdebug extension was updated or Visual Studio Code received an update.
When the debugger is active in VSCode the website works fine, when stopping the debugger, the Xdebug extension within the docker container seems to be unable to disconnect. And the website is stuck in a loading state.
I receive the following message in the xdebug.log when trying to access the site when the debugger is stopped in VSCode.
[318] Log opened at 2022-04-08 12:19:15.819009
[318] [Step Debug] INFO: Connecting to configured address/port: host.docker.internal:9001.
[318] [Step Debug] INFO: Connected to debugging client: host.docker.internal:9001 (through xdebug.client_host/xdebug.client_port). :-)
[318] [Step Debug] -> <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.0" protocol_version="1.0" appid="318" idekey="VSCODE"><engine version="3.1.4"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2022 by Derick Rethans]]></copyright></init>
This seems like the Xdebug extension still tries to connect (successfully) to the listening port at 9001.
But the port is not listening on the host, when checking with lsof -i :9001.
PHP Xdebug settings:
zend_extension=xdebug.so
xdebug.mode=debug
xdebug.remote_handler=dbgp
xdebug.idekey=VSCODE
xdebug.start_with_request=yes
xdebug.log=/tmp/xdebug.log
xdebug.client_host=host.docker.internal
xdebug.client_port=9001
xdebug.discover_client_host=0
launch.json settings:
{
"version": "0.2.0",
"configurations": [{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9001,
"log": false,
"externalConsole": false,
"pathMappings": {
"/var/www/html": "${workspaceFolder}",
},
"ignore": [
"shared/vendor/*"
]
},
]
}
I've also tried with a different client_host setting.
Added an alias to the en0 interface, to reach the host IP from Xdebug.
sudo ifconfig en0 alias 10.128.128.128 255.255.255.0
No variation of settings seems to eliminate this problem, anyone has any ideas?
The 4.8.0 build solves this issue.
The Docker for mac ticket: https://github.com/docker/for-mac/issues/6235
The builds that resolves the issue:
Intel: https://desktop-stage.docker.com/mac/main/amd64/78146/Docker.dmg
Apple silicon: https://desktop-stage.docker.com/mac/main/arm64/78146/Docker.dmg
Related
recently I need to do debug for a single file go binary application which is contained in the docker under k8s environment with its source code. When I package the docker I use the
/dlv --listen=:40000 --headless=true --api-version=2 exec /singleExeFile
and expose the 40000 port to the outer VM like
ports:
- 40000:40000
When I use my dev environment to connect to outer vm with dlv command. It seems that it can be connected. Like the following
foo#foo-vm:~$ dlv connect 110.123.123.123:40000
Type 'help' for list of commands.
(dlv)
But when use vscode to attach to the code, it meets two error(The vscode has installed go extension)
When use legacy connect, there is my launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Connect to server",
"type": "go",
"debugAdapter": "legacy",
"request": "attach",
"mode": "remote",
"port": 40000,
"host": "110.123.123.123",
"substitutePath": [
{
"from": "${workspaceFolder}/cmd/maine.go",
"to": "/singleExeFile"
}
]
}
]
}
But the vscode raises error and I haven't found similar error in google. Error: Socket connection to remote was closed
Use the dlv-dap method to connect
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Delve into Docker",
"type": "go",
"debugAdapter": "dlv-dap",
"request": "attach",
"mode": "remote",
"port": 40000,
"host": "110.123.123.123",
"substitutePath": [
{
"from": "${workspaceFolder}/cmd/maine.go",
"to": "/singleExeFile"
}
]
}
]
}
And when try to connect, there is no error raised by vscode. Just try to connect and stop by vscode. Even don't know what's the error.
With verbose param, there still isn't any output in the DEBUG console for dlv method. But for legacy method, the following error is outputted. Please check.
By the way, add verbose in legacy method and it raises some detailed message in DEBUG CONSOLE.
AttachRequest
Start remote debugging: connecting 110.123.123.123:40000
To client: {"seq":0,"type":"event","event":"initialized"}
InitializeEvent
To client: {"seq":0,"type":"response","request_seq":2,"command":"attach","success":true}
From client: configurationDone(undefined)
ConfigurationDoneRequest
Socket connection to remote was closed
To client: {"seq":16,"type":"response","request_seq":2,"command":"attach","success":false,"message":"Failed to continue: Check the debug console for details.","body":{"error":{"id":3000,"format":"Failed to continue: Check the debug console for details.","showUser":true}}}
Sending TerminatedEvent as delve is closed
To client: {"seq":0,"type":"event","event":"terminated"}
From client: disconnect({"restart":false})
DisconnectRequest
New Update in 9 July
I made another try to create a simple docker using the following dockerfile
FROM golang:1.16.15
RUN mkdir -p /var/lib/www && mkdir -p /var/lib/temp
WORKDIR /var/lib/temp
COPY . ./
RUN go env -w GOPROXY="https://goproxy.cn,direct"
RUN go install github.com/go-delve/delve/cmd/dlv#latest
RUN go mod tidy
RUN go build
RUN mv ./webproj /var/lib/www/ && rm -rf /var/lib/temp
WORKDIR /var/lib/www
COPY ./build.sh ./
EXPOSE 8080
EXPOSE 2345
RUN chmod 777 ./webproj
RUN chmod 777 ./build.sh
ENTRYPOINT ["/bin/bash","./build.sh"]
And the build.sh code is like
dlv --listen=:2345 --headless=true --api-version=2 --accept-multiclient exec ./webproj
After that, it works with GoLand debug. GoLand can debug when I send the GET api with designed. But it still can't be work with VSCode. When I use the vscode, it did connect to the docker. But when I add the break point. It shows that this is an unverified BreakPoint and can't stop.
Here is my launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Connect to server",
"type": "go",
"request": "attach",
"mode": "remote",
"remotePath": "${fileDirname}",
"port": 2345,
"host": "127.0.0.1"
}
]
}
So currently this is blocked. Help is very needed. Thanks.
problem
cannot connect with my expo app to the expo simulation
setup
set up a devcontainer with vscode's extension.
login into my expo account
successful build
expo go and laptop in the same network
has worked before with last linux pc
node -e 'console.log(os.networkInterfaces())' results:
{
lo: [
{
address: '127.0.0.1',
netmask: '255.0.0.0',
internal: true,
cidr: '127.0.0.1/8',
...
}
],
eth0: [
{
address: '172.17.0.3',
netmask: '255.255.0.0',
internal: false,
cidr: '172.17.0.3/16',
...
}
]
I tried
setting REACT_NATIVE_PACKAGER_HOSTNAME to host's ip
without it gives me a link from its eth0
open mac's firewall to vscode and docker
turn off mac's firewall
switch to tunnel connection
but this gives an error for another question later
tried posting and currently waiting responses here while exercising my google-fu
my environment
mac os 12.3 (monterey)
docker 4.7.1
devcontainer from microsoft's nodejs (alpine with node)
expo cli version: v5.3.2
previous environment
ubuntu 21.04
docker ~4.7.1
devcontainer from microsoft's nodejs (alpine with node)
expo cli version: ~5.3.2
to reproduce
setup a devcontainer
"VARIANT": "14-bullseye"
"features": {"git": "latest","aws-cli": "latest","desktop-lite": "latest","python": "latest" }
npm i -g expo-cli
expo init a new sample project
expo start
try to connect expo go via the qr
no errors on expo-cli but go-app java.net.ConnectException: Failed to connect to /192.x.x.x:19000
if not working like me:
close expo
export REACT_NATIVE_PACKAGER_HOSTNAME=192.168.1.xxx xxx is host's lan ip address
expo start
try connecting with expo go app via qr
no errors on expo-cli but go-app java.net.ConnectException: Failed to connect to /192.x.x.x:19000
I have troubles to setup debugging of py.test code in docker container using VS Code.
After studying this: https://code.visualstudio.com/docs/python/debugging
And this: How to remote debug python code in a Docker Container with VS Code
I have setup following debug configuration in vscode:
{
"name": "Python: Attach",
"type": "python",
"request": "attach",
"localRoot": "${workspaceFolder}",
"remoteRoot": "/capi",
"port": 3000,
"secret": "secret_text",
"host": "localhost"
}
I have imported this bit into my test file:
import ptvsd
ptvsd.enable_attach("secret_text", address = ('0.0.0.0', 3000))
ptvsd.wait_for_attach()
And I made sure I open that 3000 port in docker-compose file:
ports:
- 3000:3000
I double checked that the port is open:
nmap -p 3000 localhost
Starting Nmap 7.60 ( https://nmap.org ) at 2018-07-19 10:53 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000074s latency).
PORT STATE SERVICE
3000/tcp open ppp
Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
It seems to be the case. When I run pytest file from the container it starts and waits for debugger to be connected:
===================================================== test session starts =====================================================
platform linux2 -- Python 2.7.15, pytest-3.5.1, py-1.5.3, pluggy-0.6.0
rootdir: /capi, inifile:
plugins: requests-mock-1.5.0, xdist-1.14, metadata-1.7.0, html-1.16.1, cov-2.5.1
collecting 0 items
But when I run this configuration from VS Code nothing seems to happen.
It seems to hang. Nothing in the debug console or in the docker container.
I have setup remote debug for a simple hello-world.py console app just for testing and it seems to work. So my assumption is it has something to do with the fact that I'm trying to debug a pytest.
Have anyone managed to do this? I would appreciate some help.
I encountered the same issue and your post almost solves the problem.
When I tried implementing your solution I encountered the following issue:
ImportError while loading conftest '/app/tests/conftest.py'.
tests/conftest.py:36: in <module>
ptvsd.enable_attach("secret_text", address=("0.0.0.0", 5678))
E TypeError: enable_attach() got multiple values for argument 'address'
Removing the "secret_text" value allowed me to hit the wait_for_attach() point and successfully attach the debugger to the code. I was able to hit breakpoints in my tests. Thank you!
.vscode/launch.json
{
"name": "Python: Attach",
"type": "python",
"request": "attach",
"localRoot": "${workspaceFolder}/path/to/code",
"remoteRoot": "/app",
"port": 5678,
"host": "localhost"
}
docker-compose.yml
ports:
- "5678:5678"
conftest.py
import ptvsd
ptvsd.enable_attach(address=("0.0.0.0", 5678))
ptvsd.wait_for_attach()
Note: The ptvsd lines are placed after all the imports.
CLI command to execute tests:
import subprocess
import click
#click.command()
def cli():
return subprocess.call("pytest test", shell=True)
Sequence to debug tests:
docker-compose up (get container running)
docker-compose exec MODULE CONTAINER_NAME FUNCTION_THAT_EXECUTES_TEST
Attach debugger in VSCode
Tests will execute and hit whatever breakpoint you have setup.
I came across this question before discovering that Visual Studio Code has had built-in-support for remote debugging docker containers since 2019!
A quick guide I wrote to getting started
The official documentation
I have a docker container running a java process that I am trying to connect to rabbitmq running on my localhost.
Here are the steps I've done so far:
On my Local machine (macbook running Docker version 1.13.0-rc3, build 4d92237 with firewall turned off)
I've updated my rabbitmq_env.conf file to remove RABBITMQ_NODE_IP_ADDRESS so I am not tied to connect via localhost and i have an admin rabbitmq user. (not trying with guest user)
I tested this via telnet on my local machine and have no issues telnet <local-ip> 5672
Inside my docker container
able to ping local-ip and curl rabbitmq admin api
curl -i -u username:password http://local-ip:15672/api/vhosts returns sucessfully
[{"name":"/","tracing":false}]
When i try to telnet from inside the container I get
"Connection closed by foreign host"
looking at the rabbitmq.logs
=ERROR REPORT====
closing AMQP connection <0.30526.1> (local-ip:53349 -> local-ip:5672):
{handshake_timeout,handshake}
My java stacktrace incase helpful
Caused by: java.net.ConnectException: Connection refused (Connection >refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at >java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at >java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.>java:206)
at >java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at >com.rabbitmq.client.impl.FrameHandlerFactory.create(FrameHandlerFactory.ja>va:32)
at >com.rabbitmq.client.impl.recovery.RecoveryAwareAMQConnectionFactory.newCon>nection(RecoveryAwareAMQConnectionFactory.java:35)
docker network inspect bridge
[
{
"Name": "bridge",
"Id": "716f935f19a107225650a95d06eb83d4c973b7943b1924815034d469164affe5",
"Created": "2016-12-11T15:34:41.950148125Z",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Containers": {
"9722a49c4e99ca5a7fabe56eb9e1c71b117a1e661e6c3e078d9fb54d7d276c6c": {
"Name": "testing",
"EndpointID": "eedf2822384a5ebc01e5a2066533f714b6045f661e24080a89d04574e654d841",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
What am I missing?
for me this works fine!
I have been installed the image docker pull rabbitmq:3-management
and run
docker run -d --hostname haroldjcastillo --name rabbit-server -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin2017 -p 5672:5672 -p 15672:15672 rabbitmq:3-management
the most important is to add the connection and management ports -p 5672:5672 -p 15672:15672
See you host in docker
docker-machine ip
return in my case:
192.168.99.100
Go to management http://192.168.99.100:15672
For Spring Boot you can configure this or works good for another connections
spring.rabbitmq.host=192.168.99.100
spring.rabbitmq.username=admin
spring.rabbitmq.password=admin2017
spring.rabbitmq.port=5672
Best wishes
For anyone else searching for this error, I'm using spring boot and rabbitmq in docker container, starting them with docker compose. I kept getting org.springframework.amqp.AmqpConnectException: java.net.ConnectException: Connection refused from the spring app.
The rabbitmq hostname was incorrect. To fix this, I'm using the container names in the spring app configuration. Either put spring.rabbitmq.host=my-rabbit in spring's application.properties (or yml file), or in docker-compose.yaml add environment: SPRING_RABBITMQ_HOST: my-rabbit to the spring service. Of course, "my-rabbit" is the rabbitmq container name described in the docker-compose.yaml
I am using docker with linux container with rabbitmq:3-management and have created a dotnet core based web api. While calling from We API action method I faced the same issue and changed the value to "host.docker.internal"
following scenario worked for me
"localhost" on IIS Express
"localhost" on Docker build from Visual Studio
"host.docker.internal" on Docker build from Visual Studio
"Messaging": {
"Hostname": "host.docker.internal",
"OrderQueue": "ProductQueue",
"UserName": "someuser",
"Password": "somepassword" },
But facing the same issue when, the container created via docker build command, but not when container created using Visual Studio F5 command.
Now find the solution there are two ways to do it:
by default all the containers get added into "bridge" network go through with these steps
Case1: If you have already containers (rabbitmq and api) in the docker
and running then first check their ip / hostname
docker network ls
docker network inspect bridge # from this step you'll get to know what containers are associated with this
find the rabbitmq container and internal IP, apply this container name or IP and then run your application it will work from Visual Studio and Docker build and run command
Case2: if you have no containers running then you may like to create
your network in docker then follow these steps:
docker network create givenetworknamehere
add your container while using "docker run" command or after
Step2.1: if using docker run command for your container then;
docker run --network givenetworknamehere -d -p yourport:80 --name givecontainername giveyourimagename
Step2.2 if adding newly created network after container creation then use below
command docker network connect givenetworknamehere givecontainername
with these step you bring your container in your newly created same network and they can communicate.
Note: by default "bridge" network type get created
After a restart, all was working. I don't think Rabbit was using respecting .config changes
I've been putting together a POC mesos/marathon system that I am using to launch and control docker images.
I have a Vagrant virtual machine running in VirtualBox on which I run docker, marathon, zookeeper, mesos-master and mesos-slave processes, with everything working as expected.
I decided to add Chronos into the mix and initially I started with it running as a service on the vagrant VM, but then opted to switch to running it in a docker container using the mesosphere/chronos image.
I have found that I can get container image to start and run successfully when I specify HOST network mode for the container, but when I change to BRIDGE mode then I run into problems.
In BRIDGE mode, the chronos framework registers successfully with mesos (I can see the entry on the frameworks page of the mesos UI), but it looks as though the framework itself doesn't know that the registration was successful. The mesos master log if full of messages like:
strong textI1009 09:47:35.876454 3131 master.cpp:2094] Received SUBSCRIBE call for framework 'chronos-2.4.0' at scheduler-16d21dac-b6d6-49f9-90a3-bf1ba76b4b0d#172.17.0.59:37318
I1009 09:47:35.876832 3131 master.cpp:2164] Subscribing framework chronos-2.4.0 with checkpointing enabled and capabilities [ ]
I1009 09:47:35.876924 3131 master.cpp:2174] Framework 20151009-094632-16842879-5050-3113-0001 (chronos-2.4.0) at scheduler-16d21dac-b6d6-49f9-90a3-bf1ba76b4b0d#172.17.0.59:37318 already subscribed, resending acknowledgement
This implies some sort of configuration/communication issue but I have not been able to work out exactly what the root of the problem is. I'm not sure if there is any way to confirm if the acknowledgement from mesos is making it back to chronos or to check the status of the communication channels between the components.
I've done a lot of searching and I can find posts by folk who have encountered the same issue but I haven't found an detailed explanation of what needs to be done to correct it.
For example, I found the following post which mentions a problem that was resolved and which implies the user successfully ran their chronos container in bridge mode, but their description of the resolution was vague. There was also this post but the change suggested did resolve the issue that I am seeing.
Finally there was a post by someone at ILM who had what sound like exactly my problem and the resolution appeared to involve a fix to Mesos to introduce two new environment variables LIBPROCESS_ADVERTISE_IP and LIBPROCESS_ADVERTISE_PORT (on top of LIBPROCESS_IP and LIBPROCESS_PORT) but I can't find a decent explanation of what values should be assigned to any of these variables, so have yet to work out whether the change will resolve the issue I am having.
It's probably worth mentioning that I've also posted a couple of questions on the chronos-scheduler group, but I haven't had any responses to these.
If it's of any help the versions of software I'm running are as follows (the volume mount allows me to provide values of other parameters [e.g. master, zk_hosts] as files, without having to keep changing the JSON):
Vagrant: 1.7.4
VirtualBox: 5.0.2
Docker: 1.8.1
Marathon: 0.10.1
Mesos: 0.24.1
Zookeeper: 3.4.5
The JSON that I am using to launch the chronos container is as follows:
{
"id": "chronos",
"cpus": 1,
"mem": 1024,
"instances": 1,
"container": {
"type": "DOCKER",
"docker": {
"image": "mesosphere/chronos",
"network": "BRIDGE",
"portMappings": [
{
"containerPort": 4400,
"hostPort": 0,
"servicePort": 4400,
"protocol": "tcp"
}
]
},
"volumes": [
{
"containerPath": "/etc/chronos/conf",
"hostPath": "/vagrant/vagrantShared/chronos",
"mode": "RO"
}
]
},
"cmd": "/usr/bin/chronos --http_port 4400",
"ports": [
4400
]
}
If anyone has any experience of using chronos in a configuration like this then I'd appreciate any help that you might be able to provide in resolving this issue.
Regards,
Paul Mateer
I managed to work out the answer to my problem (with a little help from the sample framework here), so I thought I should post a solution to help anyone else the runs into the same issue.
The chronos service (and also the sample framework) were configured to communicate with zookeeper on the IP associated with the docker0 interface on the host (vagrant) VM (in this case 172.17.42.1).
Zookeeper would report the master as being available on 127.0.1.1 which was the IP address of the host VM that the mesos-master process started on, but although this IP address could be pinged from the container any attempt to connect to specific ports would be refused.
The solution was to start the mesos-master with the --advertise_ip parameter and specify the IP of the docker0 interface. This meant that although the service started on the host machine it would appear as though it had been started on the docker0 ionterface.
Once this was done communications between mesos and the chronos framework started completeing and the tasks scheduled in chronos ran successfully.
Running Mesos 1.1.0 and Chronos 3.0.1, I was able to successfully configure Chronos in BRIDGE mode by explicitly setting LIBPROCESS_ADVERTISE_IP, LIBPROCESS_ADVERTISE_PORT and pinning its second port to a hostPort which isn't ideal but the only way I could find to make it advertise its port to Mesos properly:
{
"id": "/core/chronos",
"cmd": "LIBPROCESS_ADVERTISE_IP=$(getent hosts $HOST | awk '{ print $1 }') LIBPROCESS_ADVERTISE_PORT=$PORT1 /chronos/bin/start.sh --hostname $HOST --zk_hosts master-1:2181,master-2:2181,master-3:2181 --master zk://master-1:2181,master-2:2181,master-3:2181/mesos --http_credentials ${CHRONOS_USER}:${CHRONOS_PASS}",
"cpus": 0.1,
"mem": 1024,
"disk": 100,
"instances": 1,
"container": {
"type": "DOCKER",
"volumes": [],
"docker": {
"image": "mesosphere/chronos:v3.0.1",
"network": "BRIDGE",
"portMappings": [
{
"containerPort": 9900,
"hostPort": 0,
"servicePort": 0,
"protocol": "tcp",
"labels": {}
},
{
"containerPort": 9901,
"hostPort": 9901,
"servicePort": 0,
"protocol": "tcp",
"labels": {}
}
],
"privileged": true,
"parameters": [],
"forcePullImage": true
}
},
"env": {
"CHRONOS_USER": "admin",
"CHRONOS_PASS": "XXX",
"PORT1": "9901",
"PORT0": "9900"
}
}