Lorsque je l'exécute docker-compose updans mon projet Docker, il échoue avec le message suivant:

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

netstat -pna | grep 3000 montre ceci:

tcp        0      0 0.0.0.0:3000            0.0.0.0:*               LISTEN      -  

J'ai déjà essayé docker-compose down, mais ça n'aide pas.

Dans votre cas, c'était un autre processus qui utilisait le port et, comme indiqué dans les commentaires, sudo netstat -pna | grep 3000vous a aidé à résoudre le problème.

Alors que dans d'autres cas (je l'ai moi-même rencontré plusieurs fois), il s'agit principalement du même conteneur fonctionnant sur une autre instance. Dans ce cas, docker psc'était très utile car je laissais souvent les mêmes conteneurs s'exécuter dans d'autres répertoires, puis j'essayais de recommencer à d'autres endroits, où les mêmes noms de conteneurs étaient utilisés.

Comment docker psm'a aidé: docker rm -f $(docker ps -aq) est une commande courte que j'utilise pour supprimer tous les conteneurs.

Edit: Ajouté comment docker psm'a aidé.

Cela m'a aidé:

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

puis: kill -9 <process id>(macOS) ou sudo kill <process id>(Linux).

Source: commentaire de l'utilisateur Rub21 .

J'ai eu le même problème,
docker-compose down --rmi all(dans le même répertoire où vous exécutez docker-compose up)
aide

Pour Linux / Unix:

Recherche simple de l'utilitaire Linux à l'aide de la commande suivante

netstat -nlp | grep 8888

Il affichera le traitement en cours sur ce port, puis tuera ce processus en utilisant le PID (recherchez un PID dans la ligne) de ce processus.

kill PID

J'ai eu le même problème. J'ai résolu ce problème en arrêtant le service Apache2 sur mon hôte.

Dans mon cas, c'était

Erreur lors du démarrage du proxy userland: listen tcp 0.0.0.0:9000: bind: adresse déjà utilisée

Et tout ce dont j'ai besoin est de désactiver l'écoute de débogage dans php storm

Dans certains cas, il est essentiel d'effectuer un débogage plus approfondi du problème avant d'arrêter un conteneur ou de tuer un processus.

Pensez à suivre la liste de contrôle ci-dessous:

1) Vérifiez votre environnement de composition de docker actuel
Exécutez docker-compose ps.
Si le port est utilisé par un autre conteneur, arrêtez-le docker-compose stop <service-name-in-compose-file>ou retirez-le en le remplaçant stoppar rm.

2) Vérifiez les conteneurs s'exécutant en dehors de votre espace de travail actuel
Exécutez docker pspour voir la liste de tous les conteneurs s'exécutant sous votre hôte.
Si vous trouvez que le port est utilisé par un autre conteneur, vous pouvez l'arrêter avec docker stop <container-id>.
(*) Parce que vous n'êtes pas dans le cadre de l' composeenvironnement d' origine , il est préférable d' utiliser d'abord docker inspect pour collecter plus d'informations sur le conteneur que vous êtes sur le point d'arrêter.

3) Vérifiez si le port est utilisé par d'autres processus exécutés sur l'hôte
Par exemple, si le port est 6379 run:

$ 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

(*) Vous pouvez également utiliser la commande lsof qui est principalement utilisée pour récupérer des informations sur les fichiers ouverts par divers processus (je suggère de courir netstatavant cela).

Donc, dans le cas de la sortie ci-dessus, le PIDest 915. Vous pouvez maintenant exécuter:

$ 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

Et voyez l'ID du processus parent ( PPID) et la commande d'exécution.
Vous pouvez également exécuter: $ pstree -s <PID>vers un affichage visuel du processus et de ses processus associés.

Dans notre cas, nous pouvons voir que le processus est probablement un démon (PPID vaut 1) - Dans ce cas, envisagez d'exécuter:
A) $ cat /proc/<PID>/statusafin d'obtenir des informations plus détaillées sur le processus comme le nombre de threads générés par le processus, ses capacités, etc. ».
B) $ systemctl status <PID>pour voir lesystemdunité qui a provoqué la création d'un processus spécifique. Si le service n'est pas critique, vous pouvez arrêter et désactiver le service .

4) Redémarrez le service Docker
Run: sudo service docker restart.

5) Vous avez atteint ce point et ..
Uniquement si cela ne met pas votre système en danger - envisagez de redémarrer le serveur.

J'ai mis à niveau mon docker cet après-midi et j'ai rencontré le même problème. J'ai essayé de redémarrer docker mais pas de chance.

Enfin, j'ai dû redémarrer mon ordinateur et cela a fonctionné. Certainement un bug.

Vérifiez docker-compose.yml, il se peut que le port soit spécifié deux fois.

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

J'ai rencontré le même problème plusieurs fois. Le redémarrage de docker semble faire l'affaire

Je résous le problème en redémarrant Docker.

docker-compose down --rmi all 

puis redémarrez votre ordinateur

Une variante de la réponse de @ DmitrySandalov: j'avais tomcat / java fonctionnant sur 8080, ce qui devait continuer. J'ai regardé le fichier docker-compose.yml et modifié l'entrée pour 8080 en une autre de mon choix.

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

A parfaitement fonctionné. (Le seul problème est que le changement sera effacé si jamais je mets à jour le projet, car il provient d'un dépôt externe.)

Juste une remarque si vous rencontrez le même problème et que vous utilisez Windows:

Dans mon cas, le processus à ma manière est juste grafana-server.exe. Parce que j'ai d'abord téléchargé la version binaire et double-cliquez sur l'exécutable, et il démarre maintenant en tant que service par utilisateur SYSTEMque je ne peux pas taskkill(pas d'autorisation)

Je dois aller dans le "Gestionnaire de service" de Windows et rechercher le service "Grafana" et l'arrêter. Après cela, le port 3000 n'est plus occupé.

J'espère que ça t'as aidé.

Celui qui utilisait le port 8888 était Jupiter et j'ai dû changer le fichier de configuration du notebook Jupiter pour qu'il s'exécute sur un autre port.

pour lister qui utilise ce port spécifique. sudo lsof -i -P -n | grep 9

Vous pouvez spécifier le port sur lequel Jupyter doit exécuter en décommentant / modifiant la ligne suivante dans ~ / .jupyter / jupyter_notebook_config.py:

c.NotebookApp.port = 9999

Si vous n'avez pas de jupyter_notebook_config.py, essayez d'exécuter jupyter notebook --generate-config. Voir ceci pour plus de détails sur la configuration de Jupyter.

Changer network_mode: "bridge" en "host" l'a fait pour moi.

Ceci avec

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"

Avant qu'il ne s'exécute sur: docker run -d --name oracle -p 1521: 1521 -p 5500: 5500 qa / oracle Je viens de changer le port en docker run -d --name oracle -p 1522: 1522 -p 5500: 5500 qa / oracle

cela a bien fonctionné pour moi!

Sur ma machine, un PID n'était pas affiché à partir de cette commande netstat -tulpnpour le port en cours d'utilisation (8080), donc je ne pouvais pas le tuer, tuer les conteneurs et redémarrer l'ordinateur ne fonctionnait pas. Donc, la service docker restartcommande a redémarré le docker pour moi (ubuntu) et le port n'était plus utilisé et je suis un gars heureux et je suis parti déjeuner.

J'obtenais l'erreur ci-dessous lorsque j'essayais de lancer un nouveau conatier- listen tcp 0.0.0.0:8080: bind: adresse déjà utilisée.

Solution: 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:* ECOUTER 12749 / java [root@ip-112-x6x-2x-xxx.xxxxx.compute.internal (aws_main) ~] #

tuer -9 12749

Ensuite, essayez de relancer le conteneur cela devrait fonctionner

`$` sudo service redis-server stop

Fait l'affaire.