[BUG] Docker thinks a port is already in use while the port is free

[derNiklaas]

Description

A few days ago, I tried to start my companies docker compose system and noticed that one service wasn't starting because Docker thinks the port was already in use. (bind: address already in use)

After days of restarting and reinstalling Docker (+ compose), it started working again after deleting the cache files from Docker.

Steps To Reproduce

Unfortunately, this bug occured randomly and I don't know how to reproduce it

Compose Version

Docker Compose version v2.20.2-desktop.1

Docker Environment

Client:
Version:    24.0.5
Context:    default
Debug Mode: false
Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.11.2-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.20.2-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-dev.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.20
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v0.1.0-beta.6
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scan: Docker Scan (Docker Inc.)
    Version:  v0.26.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scan.exe
  scout: Command line tool for Docker Scout (Docker Inc.)
    Version:  0.20.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
Images: 10
Server Version: 24.0.5
Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
runc version: v1.1.7-0-g860f061
init version: de40ad0
Security Options:
  seccomp
   Profile: unconfined
Kernel Version: 5.10.102.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 24.81GiB
Name: docker-desktop
ID: 96288c94-bbcc-429f-9ed6-6aba5f855c58
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Experimental: false
Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile

Anything else?

No response

[ndeloof]

AFAICT this doesn't seem to be a compose issue, but a docker engine one. If you have a chance to reproduce, please try running docker run -p <SUPPOSED_TO_BE_CONFLICTING_PORT>:80 nginx and confirm there's no issue doing so

[derNiklaas]

A colleague is having the same issue and got the following output after running the docker compose command and then running your command:

docker: Error response from daemon: driver failed programming external connectivity on endpoint hardcore_diffie (98585ecb1e742b304c5453d48e48c679babad9ac9a55ae3081bb08cd5a989691): Error starting userland proxy: listen tcp4 0.0.0.0:8080: bind: address already in use

They also tried running it without the compose and it worked correctly for them

[jaffe-fly]

same！centos7

Client: Docker Engine - Community
 Version:           26.0.1
 API version:       1.45
 Go version:        go1.21.9
 Git commit:        d260a54
 Built:             Thu Apr 11 10:56:30 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.0.1
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.9
  Git commit:       60b9add
  Built:            Thu Apr 11 10:55:26 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.31
  GitCommit:        e377cd56a71523140ca6ae87e30244719194a521
 nvidia:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

[andoks]

@derNiklaas: I have stumbled upon a similar issue, but what I discovered was that I had two services setup towards a docker network, with one of the services configured with a static ipv4 assignment, while the other did not have a static IP assigned.

The result of this configuration was that sometimes (particularly after hard-resets of the host system, like power outages), the second service dynamically got assigned the IP that the first service was supposed to be assigned statically, causing the first service to fail to start with an error "Error response from daemon: Address already in use", which sounds eerily familiar.