Windows x64 RabbitMQ install error with Erlang environment var (ERLANG_HOME)

53,004

Solution 1

There are several RabbitMQ control .bat files on windows. Every one you use needs to get changed to reflect the Erlang path correctly. In this example, I'm editing the rabbitmq-server.bat because it's one of the easier ones... any of the .bat files you want to run will need this hack to get them to work, with the rabbitmq_service.bat file being the most involved to adjust.

editing that rabbitmq_server.bat file, you can see on about line 48 or so there's a check to see if the erl.exe is found, but the path isn't correct:

if not exist "!ERLANG_HOME!\bin\erl.exe" (

that path does not match the file structure for the 5.9.2 version of Erlang. I fixed this by simply removing this path check from about line 48 to 58, then, where the .bat actually makes a call to the erl.exe on about line 129 which reads:

"!ERLANG_HOME!\bin\erl.exe" 

I simply hardcoded the path to my erl.exe:

"C:\Program Files\erl5.9.2\erts-5.9.2\bin\erl.exe" 

With the pathing correct, the rabbitmq .bat files will run.

Solution 2

1- Set environment variable:

Variable name : ERLANG_HOME
Variable value: C:\Program Files (x86)\erl6.4

note: don't include bin on above step.

2- Add %ERLANG_HOME%\bin to the PATH environmental variable:

Variable name : PATH
Variable value: %ERLANG_HOME%\bin

This works well.

Solution 3

I had the similar issue, modifying ERLANG_HOME in .bat files did not work. Then I tried echo %ERLANG_HOME% in command prompt, that did not print the environment variable value(I could see that ERLANG_HOME environment variable has been created under advance system settings), that lead me to believe that I need to restart server for 64 bit installation of Erlang. After rebooting server, It worked like a charm. I hope this helps someone.

Solution 4

Just to share an up-to-date answer as of 2019: On Windows Server 2019, after setting up the environment variable, a restart is required to solve the problem.

Solution 5

This problem still occurs in Erlang 18.3 (erl7.3) and RabbitMQ 3.6.9 on Windows when upgrading from any older version of RabbitMQ to version 3.6.9. The solution as already stated here is to manually set ERLANG_HOME with 'setx -m ERLANG_HOME "C:\Program Files\erl7.3"' before starting the service.

What happens is that the RabbitMQ 3.6.9 installer removes the environment variable ERLANG_HOME from the system while removing the older version of RabbitMQ. Then, when it proceeds to the installation step, it does not put back the ERLANG_HOME variable. Then, the batch files that start up RabbitMQ cannot find Erlang. They try to find Erlang's home directory using "where.exe" but it always fails after an upgrade.

RabbitMQ's installer also does not kill all of the Erlang background processes, causing many of its files to be undeletable due to the Windows "file in use" problem. This leaves behind "files in use" in %APPDATA%\RabbitMQ and "C:\Program Files\RabbitMQ." These processes are "erl.exe," "erlsrv.exe," and "epmd.exe." The RabbitMQ installer should taskkill these processes after shutting down the RabbitMQ Windows service.

RabbitMQ is rather clunky on Windows.

Share:
53,004
Kevin Won
Author by

Kevin Won

.NET developer / Team Lead Developing Enterprise Integration apps for BigCo   interested in functional techniques & Haskell.

Updated on January 14, 2021

Comments

  • Kevin Won
    Kevin Won over 3 years

    I'm ask/answering this question because it hung me up & it's likely someone else will have the same problem.

    Install of RabbitMQ x64 v2.8.6 on Windows Server 2008 x64.

    After Erlang install using default install location to C:\Program Files\erl5.9.2, I'm attempting to start the server via running the rabbitmq-service.bat. Fail:

    Please either set ERLANG_HOME to point to your Erlang installation 
    or place the RabbitMQ server distribution in the Erlang lib folder.
    

    Problem is the .bat file does not have the correct subpath. with 5.9.2 (R15B02) version of erlang. My ERLANG_HOME directory is set correctly, but the script does not use it correctly for this version of Erlang, which, it appears to this Erlang noob to have a new subdirectory called "erts-5.9.2" which is causing the problems. Maybe someone intimate with these scripts can describe how to make this work correctly without the hack workaround I'm about to describe?