Cuando ejecuto docker-compose upmi proyecto de Docker, falla con el siguiente mensaje:

Error starting userland proxy: listen tcp 0.0.0.0:3000: bind: address already in use

netstat -pna | grep 3000 muestra esto:

tcp        0      0 0.0.0.0:3000            0.0.0.0:*               LISTEN      -  

Ya lo intenté docker-compose down, pero no ayuda.

En su caso, fue algún otro proceso que estaba usando el puerto y, como se indica en los comentarios, lo sudo netstat -pna | grep 3000ayudó a resolver el problema.

Mientras que en otros casos (yo mismo lo encontré muchas veces), la mayoría de las veces es el mismo contenedor que se ejecuta en otra instancia. En ese caso, docker psfue muy útil, ya que a menudo dejé los mismos contenedores ejecutándose en otros directorios y luego intenté ejecutarlos nuevamente en otros lugares, donde se usaban los mismos nombres de contenedor.

Cómo docker psme ayudó: docker rm -f $(docker ps -aq) es un comando corto que utilizo para eliminar todos los contenedores.

Editar: Se agregó cómo docker psme ayudó.

Esto me ayudó:

docker-compose down  # Stop container on current dir if there is a docker-compose.yml
docker rm -fv $(docker ps -aq)  # Remove all containers
sudo lsof -i -P -n | grep <port number>  # List who's using the port

y luego: kill -9 <process id>(macOS) o sudo kill <process id>(Linux).

Fuente: comentario del usuario Rub21 .

Tuve el mismo problema,
docker-compose down --rmi all(en el mismo directorio donde ejecuta docker-compose up)
ayuda

Para Linux / Unix:

Búsqueda simple de la utilidad de Linux usando el siguiente comando

netstat -nlp | grep 8888

Mostrará el procesamiento ejecutándose en este puerto, luego matará ese proceso usando PID (busque un PID en la fila) de ese proceso.

kill PID

Yo tuve el mismo problema. Arreglé esto deteniendo el servicio Apache2 en mi host.

En mi caso fue

Error al iniciar el proxy de usuario: escuche tcp 0.0.0.0:9000: bind: la dirección ya está en uso

Y todo lo que necesito es desactivar la escucha de depuración en php storm

En algunos casos, es fundamental realizar una depuración más profunda del problema antes de detener un contenedor o matar un proceso.

Considere seguir la siguiente lista de verificación:

1) Verifique su actual entorno de composición Docker
Run docker-compose ps.
Si otro contenedor está usando el puerto, deténgalo docker-compose stop <service-name-in-compose-file>o retírelo reemplazándolo stopcon rm.

2) Compruebe los contenedores que se ejecutan fuera de su espacio de trabajo actual
Ejecutar docker pspara ver la lista de todos los contenedores que se ejecutan en su host.
Si encuentra que el puerto está siendo utilizado por otro contenedor, puede detenerlo con docker stop <container-id>.
(*) Debido a que no está bajo el alcance del composeentorno de origen , es una buena práctica primero usar Docker Inspect para recopilar más información sobre el contenedor que está a punto de detener.

3) Compruebe si otros procesos que se ejecutan en el host utilizan
el puerto. Por ejemplo, si el puerto es 6379, ejecute:

$ sudo netstat -ltnp | grep ':6379'
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      915/redis-server 12 
tcp6       0      0 ::1:6379                :::*                    LISTEN      915/redis-server 12

(*) También puede usar el comando lsof que se usa principalmente para recuperar información sobre archivos que son abiertos por varios procesos (sugiero ejecutar netstatantes de eso).

Entonces, en el caso de la salida anterior, PIDis 915. Ahora puedes ejecutar:

$ ps j 915
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    1   915   915   915 ?           -1 Ssl    123   0:11 /usr/bin/redis-server 127.0.0.1:6379

Y vea el ID del proceso padre ( PPID) y el comando de ejecución.
También puede ejecutar: $ pstree -s <PID>a una visualización visual del proceso y sus procesos relacionados.

En nuestro caso, podemos ver que el proceso probablemente sea un demonio (PPID es 1); en ese caso, considere ejecutar:
A) $ cat /proc/<PID>/statuspara obtener información más detallada sobre el proceso, como la cantidad de subprocesos generados por el proceso, sus capacidades, etc. '.
B) $ systemctl status <PID>para ver elsystemdunidad que provocó la creación de un proceso específico. Si el servicio no es crítico, puede detenerlo y deshabilitarlo .

4) Reiniciar servicio acoplable
Run: sudo service docker restart.

5) Ha llegado a este punto y ...
Sólo si no pone en riesgo su sistema, considere reiniciar el servidor.

Actualicé mi ventana acoplable esta tarde y encontré el mismo problema. Intenté reiniciar Docker pero no tuve suerte.

Finalmente, tuve que reiniciar mi computadora y funcionó. Definitivamente un error.

Compruebe docker-compose.yml, podría darse el caso de que el puerto se especifique dos veces.

version: '3'
services:
  registry:
    image: mysql:5.7
        ports:
      - "3306:3306"             <--- remove either this line or next
      - "127.0.0.1:3306:3306"

Me encontré con el mismo problema varias veces. Reiniciar Docker parece hacer el truco

Resuelvo el problema reiniciando Docker.

docker-compose down --rmi all 

y luego reinicia tu computadora

Una variación de la respuesta de @ DmitrySandalov: tenía tomcat / java ejecutándose en 8080, que necesitaba continuar. Miré el archivo docker-compose.yml y modifiqué la entrada de 8080 a otra de mi elección.

nginx:
  build: nginx
  ports:
    #- '8080:80' <-- original entry
    - '8880:80'
    - '8443:443'

Funcionó perfectamente. (El único inconveniente es que el cambio se borrará si alguna vez actualizo el proyecto, ya que proviene de un repositorio externo).

Solo una nota al margen si tiene el mismo problema y está con Windows:

En mi caso el proceso a mi manera es justo grafana-server.exe. Porque primero descargué la versión binaria y hice doble clic en el ejecutable, y ahora comienza como un servicio por parte del usuario SYSTEMque no puedo taskkill(sin permiso)

Tengo que ir al "Administrador de servicios" de Windows, buscar el servicio "Grafana" y detenerlo. Después de eso, el puerto 3000 ya no está ocupado.

Espero que ayude.

El que estaba usando el puerto 8888 era Jupiter y tuve que cambiar el archivo de configuración del portátil Jupiter para que se ejecutara en otro puerto.

para enumerar quién está usando ese puerto específico. sudo lsof -i -P -n | grep 9

Puede especificar el puerto que desea que ejecute Jupyter sin comentar / editar la siguiente línea en ~ / .jupyter / jupyter_notebook_config.py:

c.NotebookApp.port = 9999

En caso de que no tenga un jupyter_notebook_config.py intente ejecutar jupyter notebook --generate-config. Consulte esto para obtener más detalles sobre la configuración de Jupyter.

Cambiar network_mode: "bridge" a "host" lo hizo por mí.

Esto con

version: '2.2'
services:
  bind:
    image: sameersbn/bind:latest
    dns: 127.0.0.1
    ports:
      - 172.17.42.1:53:53/udp
      - 172.17.42.1:10000:10000
    volumes:
        - "/srv/docker/bind:/data"
    environment:
      - 'ROOT_PASSWORD=secret'
    network_mode: "host"

Antes de que se ejecutara en: docker run -d --name oracle -p 1521: 1521 -p 5500: 5500 qa / oracle Acabo de cambiar el puerto a docker run -d --name oracle -p 1522: 1522 -p 5500: 5500 qa / oráculo

funcionó bien para mí!

En mi máquina, este comando no mostraba un PID netstat -tulpnpara el puerto en uso (8080), por lo que no pude eliminarlo, eliminar los contenedores y reiniciar la computadora no funcionó. Entonces, el service docker restartcomando reinició la ventana acoplable para mí (ubuntu) y el puerto ya no estaba en uso y soy un tipo feliz y me voy a almorzar.

Recibí el siguiente error cuando intentaba iniciar un nuevo conatier: escuche tcp 0.0.0.0:8080: bind: address ya está en uso.

Solución: netstat -tulnp | grep 8080

[root@ip-112-x6x-2x-xxx.xxxxx.compute.internal (aws_main) ~] # netstat -tulnp | grep 8080 tcp 0 0 0.0.0.0:8080 0.0.0.0:* ESCUCHAR 12749 / java [root@ip-112-x6x-2x-xxx.xxxxx.compute.internal (aws_main) ~] #

matar -9 12749

Luego intente reiniciar el contenedor, debería funcionar

`$` sudo service redis-server stop

Hace el truco.