Hello guys, I have this problem that occurs from time to time and I couldn’t force it, I just wanted to know if it’s a version problem or if it’s a bug that occurs in the latest versions of docker, the error is Bind for 0.0.0.0:9994 failed: port is already allocated but the real problem is, the port 9994 is not being used for any process, let me show the details:
root@data-manipulation-18:/opt# docker ps | grep 9994
root@data-manipulation-18:/opt# docker-compose version
Docker Compose version v2.35.1
root@data-manipulation-18:/opt# docker version
Client:
Version: 26.1.3
API version: 1.45
Go version: go1.22.2
Git commit: 26.1.3-0ubuntu1~20.04.1
Built: Mon Oct 14 22:06:01 2024
OS/Arch: linux/amd64
Context: default
Server:
Engine:
Version: 26.1.3
API version: 1.45 (minimum version 1.24)
Go version: go1.22.2
Git commit: 26.1.3-0ubuntu1~20.04.1
Built: Mon Oct 14 22:06:01 2024
OS/Arch: linux/amd64
Experimental: true
containerd:
Version: 1.7.24
GitCommit:
runc:
Version: 1.1.12-0ubuntu2~20.04.1
GitCommit:
docker-init:
Version: 0.19.0
GitCommit:
root@data-manipulation-18:/opt# lsof -i :9994
root@data-manipulation-18:/opt# docker-compose up -d
WARN[0000] /opt/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion
[+] Running 0/1
⠙ Container devoz-proxy Starting 0.2s
Error response from daemon: driver failed programming external connectivity on endpoint devoz-proxy (1d22335933a88214aff07900446e12774a77ae53f49004024a58a66c4fef86b9): Bind for 0.0.0.0:9994 failed: port is already allocated
Logs from journalctl:
Jun 12 17:43:17 data-manipulation-18 dockerd[1072]: time="2025-06-12T17:43:17.814951294Z" level=info msg="No non-localhost DNS nameservers are left in resolv.conf. Using default external servers"
Jun 12 17:43:17 data-manipulation-18 dockerd[1072]: time="2025-06-12T17:43:17.820453366Z" level=warning msg="Failed to allocate and map port 9994-9994: Bind for 0.0.0.0:9994 failed: port is already allocated"
Jun 12 17:43:17 data-manipulation-18 dockerd[1072]: time="2025-06-12T17:43:17.891863224Z" level=error msg="Handler for POST /v1.45/containers/73821860cfbdbeda6be3584064f618c1d68b7ed65b7c3dc5237c9f366bf22af0/start returned error: driver failed programming external connectivity on endpoint devoz-proxy (b90dd2f46ae92a94fc4e3bb7f1b33320e27e34a59ad8c3493ec16ae135600356): Bind for 0.0.0.0:9994 failed: port is already allocated" spanID=ef50dded8de04bdc traceID=604fb3750fff5ff00b2347f91663551b
First i checked if any container was using this port, none were using it. A tried to see if any process was using this port and nothing again. This docker-compose up only created the container, i tried docker-compose down and them up again, removed the container created and up again, killed the process using the port 9994, none of this worked until restart the service, but this solution could cause damage to our customers in an production environment, so this option is the last i wanna use, is there any other workaround ?
Which service did you restart? The docker daemon itself?
I don’t know if the daemon had this issue, but I don’t think v26 is still supported, so even if you had an extended support for Ubuntu 20.04, I would recommend updating Docker to at least v27 in a production environment soon.
I also noticed you use docker-compose up which is usually not the compose v2 unless Docker Desktop is installed, but yours is. So can you share how Docker was installed?
We usually need the following information to understand the issue:
What platform are you using? Windows, Linux or macOS? Which version of the operating systems? In case of Linux, which distribution?
How did you install Docker? Sharing the platform almost answers it, but only almost. Direct links to the followed guide can be useful.
On debian based Linux, the following commands can give us some idea and recognize incorrectly installed Docker:
docker info
docker version # already shared
Review the output before sharing and remove confidential data if any appears (public IP for example)
I just remembered to share the docker version, sorry; if there was a template, it could avoid these errors, anyways, I restarted docker.service (systemctl restart docker.service) not the socket. This happened on an ubuntu server.
We installed with the docker repository (“deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable”) and them apt install docker-ce docker-ce-cli containerd.io
The docker-compose we installed with this "curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose"
dpkg output: ii docker.io 26.1.3-0ubuntu1~20.04.1 amd64 Linux container runtime
snap list docker error: no matching snaps installed
If you think we installed incorrectly please tell us, i didnt even know there was a corret way
Ubuntu 20 is un-supported since last month, unless you have a special contract.
Ubuntu long-term support releases (LTS) are released every 2 years by Canonical. Canonical provides patching and maintenance for Ubuntu LTS releases for 5 years for all packages in the main repository. For Ubuntu 20.04 LTS, this support will last until 31 May 2025.
I recommend to upgrade to a newer version to get security and bug fixes.
Also dependencies like Docker will not be supported on such an out-dated OS version (doc).
We know its un-supported, we have more than 250 servers, we are updating them but it will take some time, i just want to know if anyone has experienced in the newest versions of docker, because i dont know how to reproduce this errors.
Are you sure? Because you have the docker.io package according to your other output
Which is a package maintained by the maintainers of Ubuntu. If you installed from the repo you quoted, you would have docker-ce and docker-ce-cli in the dpkg output, not docker.io.
I usually don’t recommend docker.io, because I had issues with it years ago. The official installation guide also starts with the commands to remove docker.io. I’m not saying that package is the cause of the issue, it may be completely fine today, I don’t know..
I’m not sure how it was downloaded, because we use templates and we don’t have documented how it was downloaded so, in your experience, docker.io is worse than downloading the official version ?
So if there i a problem with that package, you would need to ask the help of the Ubuntu developers even though they also use the moby project as a base which is the base of Docker CE as well. I can’t say that docker.io is worse, but I had bad experiences in the past, yes. Using a package maintained by the maintainers of the operating system could have its benefits too, since they can decide patching it to fix issues even when the official packages are not patched anymore. but Docker, as a company supports Docker CE and Docker Desktop that also contains Docker CE.
Most of the users who can help here, are also using Docker CE, if not all. So if anything is different, if any error can happen with the docker.io package that didn’t happen with Docker CE, nobody would be able to reproduce it. And if there was a bug somewhere in the moby project, a fix could be shipped with Docker CE, and I have no information about how the docker.io package is maintained exactly.
so, in your experience,