Please, give us a precise description (what does not work, what is expected, etc.)
Trying to run ejabberdctl iexlive, it is not starting with elixir shell it but just shows this error after the warning message
/opt/ejabberd-21.01/bin/elixir: 126: exec: erl: not found.
Googling a bit gave me this issue, but according to that it was supposed to have already been fixed somewhere in version 17.
Erlang version: 10.3.4
Installed from: official binary installer
The ejabberd binary installers published by ProcessOne already include the required libraries from Erlang/OTP. So, it isn't needed to install erlang to run that ejabberd installation. Of course, it doesn't hurt to have it installed.
Trying to run ejabberdctl iexlive, it is not starting with elixir shell it but just shows this error after the warning message
/opt/ejabberd-21.01/bin/elixir: 126: exec: erl: not found.
Right, I see that problem with 21.01, and also with older installers... even with 17.09, which included that fix.
$ cd ejabberd-21.01/
$ ./bin/ejabberdctl iexlive
.../ejabberd-21.01/bin/elixir: 126: exec: erl: not found
I found a workaround, simply export ERL_PATH like this:
$ export ERL_PATH=`pwd`/bin/erl
$ ./bin/ejabberdctl iexlive
...
13:54:39.624 [info] ejabberd 21.01 is started in the node ejabberd@localhost in 4.30s
iex(ejabberd@localhost)1>
Now that it finally starts, I can see some errores about Elixir.Logger. This is because the ejabberd 21.01 installer includes Elixir 1.4.4 and Erlang/OTP 21, but those are incomplatible as mentioned in
https://hexdocs.pm/elixir/compatibility-and-deprecations.html#compatibility-between-elixir-and-erlang-otp
simply export ERL_PATH like this
Oh yes, seems to work now with that env variable. Thanks 馃憤
Ok, then you can make this permanent, simply editing ejabberdctl and adding the line there:
diff a/bin/ejabberdctl b/bin/ejabberdctl
index 54dd07f..dbd7d73 100755
--- a/bin/ejabberdctl
+++ b/bin/ejabberdctl
@@ -135,6 +135,7 @@ exec_erl()
exec_iex()
{
NODE=$1; shift
+ export ERL_PATH=$ERL
exec_cmd "$IEX" -${S:--}name "$NODE" --erl "$ERLANG_OPTS" "$@"
}
I expect this is already fixed, and will be correct in the next packages. Let's keep this issue open, and check it for sure when they are published.