RABBITMQ_MNESIA_BASE set in the rabbitmq-env.conf file is ignored but MNESIA_BASE is not #401

lukebakken · 2020-07-07T13:49:48Z

https://vmware.slack.com/archives/C055BSG8E/p1594049782287100

https://rabbitmq.slack.com/archives/C1EDN83PA/p1594046979401900

I upgraded a cluster from 3.7.11 to 3.8.5 today. Upon starting 3.8.5, and after some investigation, it appears to be ignoring the /etc/rabbitmq/rabbitmq-env.conf file, which has RABBITMQ_MNESIA_BASE set to the location of the mnesia database. As a result it's trying to find the database in /var/lib/rabbitmq, and then creating a new database there.
Has something changed? I've checked through the website and from what I'm reading the location of the rabbitmq-env.conf file hasn't changed, nor has this variable name. For now I've had to roll back go 3.7.11 to get things working again.

From @dumbbell -

My analysis of the problem: before soucing the env file in rabbit_env, we pass it all variables it can expect (setting them to default values). $MNESIA_BASE is among them. When we read the result of the script, we handle variable in alphabetical order. The script returns both $MNESIA_BASE and $RABBITMQ_MNESIA_BASE in the case of those end-users: the former because we set it before calling it, the latter because the file defines it. Because of the alphabetical order, $MNESIA_BASE is handled first: it is not in the environment, so we export it (so rabbit_env picks it). When we handle $RABBITMQ_MNESIA_BASE, we check if the variable is already exported (which is the case because of $MNESIA_BASE), thus it is ignored.

…output of $CONF_ENV_FILE When we source the $CONF_ENV_FILE script, we set a few variables which this script expects. Those variables are given without their prefix. For instance, $MNESIA_BASE. The $CONF_ENV_FILE script can set $RABBITMQ_MNESIA_BASE. Unfortunately before this patch, the variable would be ignored, in favor of the default value which was passed to the script ($MNESIA_BASE). The reason is that variables set by the script are handled in the alphabetical order. Thus $MNESIA_BASE is handled first, then $RABBITMQ_MNESIA_BASE. Because the code didn't give any precedence, the first variable set would "win". This explains why users who set $RABBITMQ_MNESIA_BASE in $CONF_ENV_FILE, but using RabbitMQ 3.8.4+ (which introduced `rabbit_env`), unexpectedly had their node use the default Mnesia base directory. The patch is rather simple: when we check if a variable is already set, we give precedence to the $RABBITMQ_* prefixed variables. Therefore, if the $CONF_ENV_FILE script sets $RABBITMQ_MNESIA_BASE, this value will be used, regardless of the value of $MNESIA_BASE. This didn't happen with variables set in the environment (i.e. the environment of rabbitmq-server(8)) because the prefixed variables already had precedence. Fixes #401.

lukebakken assigned dumbbell and lukebakken Jul 7, 2020

lukebakken transferred this issue from rabbitmq/rabbitmq-server Jul 7, 2020

dumbbell mentioned this issue Jul 7, 2020

rabbit_env: Give precedence to $RABBITMQ_* prefixed variables in the output of $CONF_ENV_FILE #402

Merged

dumbbell added the bug label Jul 7, 2020

dumbbell added this to the 3.8.6 milestone Jul 7, 2020

michaelklishin closed this as completed in #402 Jul 8, 2020

michaelklishin changed the title ~~MNESIA_BASE regression in 3.8.4 and later versions~~ RABBITMQ_MNESIA_BASE set in the rabbitmq-env.conf file is ignored but MNESIA_BASE is not Jul 8, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RABBITMQ_MNESIA_BASE set in the rabbitmq-env.conf file is ignored but MNESIA_BASE is not #401

RABBITMQ_MNESIA_BASE set in the rabbitmq-env.conf file is ignored but MNESIA_BASE is not #401

lukebakken commented Jul 7, 2020

RABBITMQ_MNESIA_BASE set in the rabbitmq-env.conf file is ignored but MNESIA_BASE is not #401

RABBITMQ_MNESIA_BASE set in the rabbitmq-env.conf file is ignored but MNESIA_BASE is not #401

Comments

lukebakken commented Jul 7, 2020