Closed weiss closed 2 years ago
Thanks. But weird that the command line kernel option is a tuple and not just an ip string. I don't like having to parse that in shell script :( but I guess no way around it.
I don't like having to parse that in shell script :(
Yes, ugliness :unamused:
I guess no way around it.
I see no way, except maybe giving up on the idea of specifying the address to use by the main node and by erl_call
in a single place. I.e., just add some RPC_ADDRESS
(or whetever) variable for erl_call
to use, and let the user specify both inet_dist_user_interface
and that new variable. (Would be good enough for me personally, and would allow for keeping the inet_dist_user_interface
setting in sys.config
, where it looks less ugly to me. But would be ugly in a different way.)
I see no way
Well I guess another way would be using Erlang instead, e.g. something along the following lines. But it's probably preferable not to spin up the VM for that job.
# Convert {127,0,0,1} to 127.0.0.1
addr_tuple_to_str() {
addr="$1"
code="catch io:format(\"~s\", [inet:ntoa($addr)]), halt()."
result="$("$BINDIR/erl" -noinput -boot no_dot_erlang -eval "$code")"
if [ -n "$result" ]; then
printf '%s' "$result"
else
echo "Cannot parse IP address tuple: '$addr'" >&2
fi
}
Oh, duh, its using a tuple because its using -kernel ...
so it is not an exposed erl
arg like my original thinking.
Oh, duh, its using a tuple because its using
-kernel ...
so it is not an exposederl
arg like my original thinking.
Yes. That's the (only) way of telling the VM to dist-listen on localhost
, I think? Which doesn't seem like an obscure use case to me? (I just want to use the extended start script for controlling my daemon, rather than running an actual cluster.)
Not obscure at all. Something we should have supported for using the shell, rpc, etc stuff a long long time ago :).
I think this is good, just being cautious since tiny changes in this particular code has broken certain users before. It is a mess.
just being cautious since tiny changes in this particular code has broken certain users before. It is a mess.
Totally makes sense, I'm very happy with such detailed review! :+1:
Support specifying the kernel option
inet_dist_use_interface
in thevm.args
file. IfERL_DIST_PORT
is set while using Erlang/OTP 23 or newer, make sure to hand over theinet_dist_use_interface
address toerl_call
's-address
option.My own use case is binding the VM to
127.0.0.1
(if not actually running a cluster) and still being able to useERL_DIST_PORT
.