I can reproducibly make the startup of rabbitmq-server fail by setting some unrelated environment variables.
I can workaround the issue by unsetting these environment variables when starting rabbitmq-server, but I think that this deserves fixing upstream.
What follows is the script that I use to reproduce the issue.
#!/usr/bin/env bash
declare -x shellHook="
function isShellInteractive {
# shell is interactive if \$- contains 'i'
[[ \$- == *i* ]]
}
"
export RABBITMQ_PID_FILE=/tmp/rabbit.pid
export RABBITMQ_CONF_ENV_FILE=$PWD/rabbitmq-env.conf
echo -e "MNESIA_BASE=/tmp/mnesia\nLOG_BASE=/tmp/log" > rabbitmq-env.conf
rabbitmq-server
Running it results in:
15:40:04.915 [warning] Failed to parse $RABBITMQ_CONF_ENV_FILE output: "}"
15:40:05.180 [error] CRASH REPORT Process <0.243.0> with 0 neighbours crashed with reason: no match of right hand value {error,enoent} in ra_system_sup:init/1 line 19
...
This issue was introduced somewhere between v3.8.3 and v3.8.4. I was not yet able to bisect it further.
@knedlsepp that does not really explain what you were trying to set unrelated variables in rabbitmq-env.conf. It's not meant to be used as a way to execute arbitrary code around RabbitMQ startup, only define a known number of environment variables. Our small team has to allocate our resources wisely and this sounds like a potentially massive time sink and a potential attack vector if we try to support arbitrary shell code in that file.
And your script probably means to redirect to rabbitmq-env.conf, not rabbitmq.conf (which does not support environment variables in any way).
@michaelklishin Thank you for your response.
that does not really explain what you were trying to set unrelated variables in rabbitmq-env.conf
Right. I was not trying to do custom things as part of the rabbitmq-env.conf. The shellHook environment variable is something that is set as part of a development environment in which I manually run the rabbitmq-server command.
And your script probably means to redirect to rabbitmq-env.conf, not rabbitmq.conf (which does not support environment variables in any way).
You're right about that, I'll fix the typo.
Hi!
Thanks, it's probably a genuine bug.
Could you please indicate what is your /bin/sh shell? That's the one we use to load rabbitmq-env.conf from the Erlang code. We parse the output of set and don't handle a particular syntax probably.
Small correction: we use sh found in the $PATH. It might not be /bin/sh.
My global /bin/sh is GNU bash, version 4.2.46(2)-release, but on $PATH I have GNU bash, version 4.4.23(1)-release.
Thank you! I will try to reproduce and will keep you posted.
Hi @knedlsepp!
I believe I reproduced the issue, thanks to your script. I prepared a patch which hopefully fixes the problem. Could you please try it in your environment?
It is against the master branch, so what will become the next minor release. Once the fix is confirmed, I will backport to 3.8.x.
Thank you for the fast fix. To be honest I'm struggling a little right now to build your pull-request from source. Is there a simple way to retrieve the build artifacts from travis? Otherwise it will probably take me a bit to report back.
Travis doesn't publish artefacts. I can build one for you and publish it to this GitHub issue.
Ah, GitHub refuses tar archives. I uploaded the file to Google Drive then:
https://drive.google.com/file/d/115i1Os_1FlRTOk2SElN3gvT99KvqoEWI/view?usp=sharing
This is a generic-unix package compiled with Erlang 23.3. Is it ok with you?
@dumbbell Thank you for helping me out here with the artifacts.
I did run the following test now:
rabbitmq-server 3.8.4 using erlang 22.1.7rabbitmq-server from your tarball runs successfully using erlang 23.3.1Thank you for solving this issue in such short amount of time!
@knedlsepp: Awesome, thank you for testing! I will merge the patch then.
We will backport after 3.8.15 ships.