Container with rabbitmq:3.11-management failed to start

[volkerfrank]

Hi,
we pulled the lastest 3.11.18-management image, we are not able to start the container.
The 3.11.18-management-alpine and the 3.11.17-management image starts without problem.
Error is:
Failed to create thread: Operation not permitted (1)
Aborted
Our system is a debian 11.7 with docker 20.10.23.
May be this is a problem with the update to ubuntu 22.04 in the 3.11.18-management image with the last commit?
Regards
Volker

[samtregar]

I'm having the same problem with Rabbit 3.9 and with latest. It started sometime in the last three weeks but I haven't been able to pin down a cause or find a workaround.

[d1618033]

Might be related to the fact that the latest rabbitmq is using ubuntu22 as a base (0192a91) and there's this issue with threads when running an ubuntu22 container from an old ubuntu (e.g 16)
https://askubuntu.com/questions/1405417/20-04-vs-22-04-inside-docker-with-a-16-04-host-thread-start-failures

[michaelklishin]

Ubuntu 16.04 is seven years old and out of support by most software now, explicitly or not (e.g. it has old glibc, kernel and OpenSSL versions that matters in practice).

The thread mentioned by @d1618033 (thanks!) offers a workaround.

However, Debian 11 is from 2021. So this must be a Docker host/container incompatibility of some kind.

@tianon @yosifkit do we care to revert 0192a91? For RabbitMQ the (container) OS image should be mostly irrelevant (as long as we can build latest Erlang, OpenSSL, and the kernel is reasonably new). Alternatively we can Ubuntu 22.04 to 3.12.x, although I see how that would be a maintenance burden for you folks.

[tianon]

Sorry for the delay in getting on this -- this is the same seccomp denials we've seen in other images who've updated base (Ubuntu actually had them first back with 22.04, as seen in the linked thread). The correct fix for affected users is to ensure the host is on a recent enough libseccomp2, Docker, and runc combination.

I'm currently running Debian 11, and do not experience this issue, for example (my libseccomp2 is 2.5.1, runc is 1.1.7, and Docker is 20.10.24; this is also part of why runc --version includes the libseccomp version in it 😅).

(Adding --security-opt seccomp=unconfined is the "least insecure" workaround, but it should be treated as just that: a workaround. The correct fix is updating the host, as described above.)

[mik3fly]

Hello, indeed, updating the libseccomp2and runc libs solved our problem too. We also restarted the docker service and everything was fine.

We use docker 20.10.17 / amazon linux 2 / libsecomp-devel 2.4.1 / runc 1.1.7

[lukebakken]

Closing because a fix is available (update your host software!)