Protocol 'inet_tcp' the name myapp@127.0.0.1 seems to be in use by another Erlang node

Questions / Help
1

Hi guys,

Don’t understand what’s going on. This app is 100% not running on my machine:

$ epmd -names
epmd: up and running on port 4369 with data:

$ ps auxwww | grep beam.smp
zab           20704   0.0  0.0 34253876    948 s000  S+    5:41PM   0:00.00 grep beam.smp

$ ps auxwww | grep rebar3
zab           20704   0.0  0.0 34253876    948 s000  S+    5:41PM   0:00.00 grep beam.smp

But whenever i try to start it, i got this error:

$ cat ./etc/vm.args
-sname myapp@127.0.0.1
-setcookie 60H25Z_28V5I

$ ERL_FLAGS="-args_file ./etc/vm.args" rebar3 shell
[... compiling...]
Protocol 'inet_tcp' the name myapp@127.0.0.1 seems to be in use by another Erlang node

Even if i try it on another machine, i got the same error.
I also tried to use “-sname” but with no luck.

Erlang: Erlang/OTP 24 [erts-12.1]
Linux: Ubuntu 20.04LTS
1 Like
2

I’ve located the code throwing this error here: net_kernel.erl

1 Like
3

One thing that looks off is “./etc/vm.args” (in ERL_FLAGS) is not the same as “.etc/vm.args” (your cat command)

1 Like
4

Forgot to mention you can pass the values as arguments.

rebar3 shell --sname myapp --setcookie 60H25Z_28V5I

see

rebar3 help shell
2 Likes
5

@LeonardB Many thanks. This temporarly solves my issue. Still don’t understand why this is failing:

ERL_FLAGS="-args_file ./etc/vm.args" rebar3 shell
1 Like
6

May there be a problem because you set a long name (with domain) under sname option in vm.args?

1 Like
7

@mmin sorry, was a copy/paste mistake in my original post.
I tried both with:

-name myapp@127.0.0.1

and also:
-sname myapp
1 Like
8

So, when you pass values directly from CLI it works?

If not, can you shrink it down to minimal example? Do you maybe start other nodes inside your app?

2 Likes
9

@mmin Yes, from the CLI it works as expected. I don’t start nor connect to any other node.
I will try to find a minimal example reproducing this. Many thanks.

2 Likes
10

That’s really weird… Which exact version of Erlang are you using? Also, can you paste rebar.config file here?

1 Like
11

Hi, I have the same problem.

Even used inet_tcp and/or inet_tls. My releases are made in rebar3 (3.19, 3.20), I’m using esl-erlang from erlang-solutions even the last version 25.0.4 since Debian does not support newer versions of Erlang. Running apps from systemd.

One thing which seems related may be that those apps are running in virtual machines - we are using Linode. I do not remmember this problem when OS runs directly on hardware.

Does anybody have similar problem? Have anybody already found a solution? Thanks.

1 Like
12

Hi,
Can you fix the problem by passing arguments in CLI, like @zabrane did?
Can you shrink it to minimal example and paste rebar.config here?

If you’re running in virtual machine, does it have rights to access loopback interface (127.0.0.1)? Can you try it on different domain?

1 Like
13

I can use CLI, that is actually the way how to run the app - I change sname in vm.args field of the release installation. But It cannot/should not be done in an automatic way. I’d rather solve this problem.

The problem is with mnesia’s schema which is named after the nodename, isnt’it?

We use complete virtual machine, I’d guess it is KVM guest with all common network interfaces (lo, ethN, …) available.

14

If so, why does passing arguments directly helps? Do you use any rebar3 plugins?
@Agnostic can you try to replicate it outside VM?

15

Good Point, let me check if the schema is correct. There might be a problem with non-existing tables caused by renaming of the nod which I was recently investigating.

Ad rebar3 plugins? ProtoBuff and hex.pm AFAIK, no others.

Thank you for your interest in the issue.

16

Well I checked Mnesia behaviour and it collides as expected - same directory but different node name gotten from commandline causes Mnesia to not work with schema in same directory created under different node.

The main problem then can be solved by rebooting the server and then starting application/release under proper nodename (taken from vm.args in release).