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 fail. /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