Docker issue on Clear Linux

General Discussion
1

I have docker running on 2 Clear Linux machines for several years now. It looks like there is an issue with the current docker app with errors such as the following occuring on both my CL instances.

$ docker restart portainer
Error response from daemon: Cannot restart container portainer: driver failed programming external connectivity on endpoint portainer (1bd3e4e8696296739a07c07dcc65e1c9c752117f0a622d70c971892041b6664a): Error starting userland proxy: listen tcp [::]:9443: bind: address already in use

netstat -a |grep 9443 – returns nothing

CL is 39540. I have a temporary resolution by rolling back to an earlier snapshot of the VM.

Any suggestions?

1 Like
2

This a change with newer docker, -p seems to want an address 127.0.0.1:8080:8080 for instance.

4 Likes
3

Thanks. I see the same behavior on containers that use the host bridge and those that use a docker subnet. It’s weird that a localhost (127.0.0.1) would be used.

Removing single ports from a multi-port container just moved the problem to the next port to fail.

I’ll try on a non-CL host as well. I have a set of well-used bash scripts that will set up easily elsewhere.

4

I to was experiencing the same issue with Docker 24.0.2 on CL. My work-a-round was to simply designate the host address of “0.0.0.0:xxxx:xxxx” when using -p. For example, -p 0.0.0.0:9443:443
Docker 24.0.2 on Debian Bullseye does work as one would expect when using -p 9443:443.

Having to put “0.0.0.0” for the host IP is not limited to the docker run command. I had to put it in my compose files as well. I haven’t dug in to this yet as my work-a-round was a quick and easy enough fix. I suspect something with how the docker service is handing things off to docker-proxy in CL … or some obscure permission/daemon setting?

1 Like
5

@exiguus your work-a-round of adding the 0.0.0.0 got me going, so thanks. What I thought was a docker-compose oddity described above goes for a simple ‘docker run’ as – I’ve narrowed it to the simple case of:

root@sivan83 /opt/DOCKER # docker run --name test-nginx -d -p 8080:80 nginx
019e51fc27d82245526ef60553e4f65fc9379ed5e14e291492a1ad125875a4a0
docker: Error response from daemon: driver failed programming external connectivity on endpoint test-nginx (2c5128547d5ceedf86487f0f5cdf4d99e1a5fb0a6724aa2a1fe4630e9d0b9ec4): Error starting userland proxy: listen tcp [::]:8080: bind: address already in use.
6

Thanks! That 0.0.0.0:port:port workaround allowed me to get DNS service back online.

On a test machine I was able to get this to work:

sudo swupd repair --verbose --version 39300 --bundles=containers-basic --force

sudo swupd autoupdate --disable

Then reboot and containers run as normal again. Once this bug is resolved, then I will turn on autoupdate.

7

Is this a bug or just a breaking change?

I couldn’t find anything about either so could you please share some sources.

8

It has been raised as a bug (2927). A previous reported issue (2918) had been closed.

1 Like
9

Issue seems to be fixed in CL39840. So now docker scripts without the explicit host ip address (e.g. 192.168.x.x) or the unspecified address (e.g. 0.0.0.0) will function as normal.

docker run --rm --name test-nginx -d -p 8080:80 nginx

So, if you’ve turned off autoupdates, they can be put back on.

sudo swupd autoupdate --enable

1 Like