Docker – port prevents listening
- I am using Docker for Mac 1.12.0-rc2-beta17 with the “native” docker machine
I have a container, with xdebug installed, exposing port 9000 and mapping it to the port 9000:
- Docker: /etc/hosts not automatically updated on source container restart
- Why am I seeing docker.io infront of the docker images repository name?
- How to allow users to run (but not manage) docker containers?
- Docker Linking in C# - What is best way to discover Environmental Variables Injected Through Linking
- Ubuntu 16.10 in Docker 1.12 claims there is no socket for MySQL
- how to permanently set environment variable for boot2docker
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6950c2a2b05d app "/usr/bin/supervisord" 9 minutes ago Up 9 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:2222->22/tcp app_1
When I’m trying to use PhpStorm to listen to the port 9000 for debug connections, I’m getting an error “Cannot listen: port 9000 is busy”.
I must precise that I’m a newbie in networks..
3 Solutions collect form web for “Docker – port prevents listening”
It dependent how you want to connect via Xdebug
xdebug.remote_connect_back=1 said that PHP will wait until a HTTP request with GET parameter
XDEBUG_SESSION_START=<IDE_key>. Then will PHP within the server try to connect back via port 9000 where your PHPStorm is listing. Classic don’t call us, we will call you situation.
Now your situation with docker say simple, your container is responsible for port 9000. So PHP will get a loopback and PHPStorm isn’t able to use port 9000 because its already used by your docker container.
So skip the assignment of port 9000 to docker, that will fix this situation.
Firstly check your container logs to debug:
docker logs 6950c2a2b05d
docker logs app_1
-f flags for
docker logs -f app_1
Two things I discovered:
- There is no need to expose the port 9000 on a container with xdebug (that seems rather counter-intuitive for me, as I do not exactly understand how my IDE connects to xdebug then).
- I was able to use xdebug using the workaround described in https://forums.docker.com/t/ip-address-for-xdebug/10460/4.