-
Notifications
You must be signed in to change notification settings - Fork 432
Mounting volume + RABBITMQ_NODENAME env var crashes the container #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I saw this is actually a RabbitMQ behavior, and not the container behavior: |
This is crearly not a problem in the Dockerfile. Should we put something in the project's README that alerts about this behavior? It is, after all, right there where I found about this functionality! |
This is definitely bizarre and shouldn't be happening from what I can tell. I'm not seeing anywhere on that page that says "it's supposed to crash". 👍 |
It seems the error is that it is trying to cluster with the old container. Perhaps there is a way to disable this? =INFO REPORT==== 2-Feb-2015::16:55:38 ===
node : my-rabbit@16210be19e7f
...
Error description:
{boot_step,database,
{error,
{failed_to_cluster_with,
['my-rabbit@afbf88f6346f'],
"Mnesia could not connect to any nodes."}}} |
+1, same error here. Setting --hostname worked for me. |
Hi! The problem here is that the container's hostname changes between both runs but this hostname is stored by Mnesia (a database provided by Erlang standard library) in
The default node name is You can't reuse a Mnesia directory created with one node in another node. So the crash is somewhat expected because Mnesia is lost. If you want to keep |
I saw this: when mounting a host directory into
/var/lib/rabbitmq
, setting the "Node Name" with RABBITMQ_NODENAME environment variable crashes the container when re-generated.This behavior is not observed when the node name is set with the
--hostname
option:Checking the logs, this is the difference:
Log output extract when --hostname option is set:
Log output extract when RABBITMQ_NODENAME is set:
I heavily suspect this is not the expected behavior (please confirm it)
I'll fork & check it out anyways :)
The text was updated successfully, but these errors were encountered: