[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#956152 closed by Thomas Goirand <zigo@debian.org> (Re: Processed: rabbitmq-server: fails to install reliably on arm64)

On Fri, Apr 10, 2020 at 07:42:46PM -0300, Antonio Terceiro wrote:
> On Fri, Apr 10, 2020 at 08:53:18PM +0200, Paul Gevers wrote:
> [...]
> > That said, on the ci.debian.net infrastructure, we're not doing anything
> > weird. We bootstrap lxc containers and we install packages into it.
> > Maybe Antonio can chime in to add any oddities but I am not aware of
> > any,
> [...]
> amd64 and arm64 are setup in the exact same way, so even if the setup
> had something weird (not the case), that wouldn't explain why it only
> fails on arm64.

Actually, I now realized there is a difference on arm64: we run multiple
containers simultaneously, they are in the same virtual network, and all
of them have the same hostname internally. Because of the way rabbitmq
(and to some extent, erlang) works, whenever there are two containers
trying to start rabbitmq at the same time the one that comes later will

/var/log/rabbitmq/startup_log contains:
ERROR: node with name "rabbit" already running on "autopkgtest-unstable-amd64"

(this is local test on an amd64 buster vm)

This is fixed in testing/unstable (each container sees a hostname that
matches the container name). We have a few options, from changing our
arm64 setup to run a single container per host, changing the container
networking setup so that containers can't see each other, to trying a
lxc stable update.

Requiring unique hostnames is designed into stfuf like erlang, I don't
think this is something that can be realistically fixed in
rabbitmq-server. Unless the maintainers see a way out?

Attachment: signature.asc
Description: PGP signature

Reply to: