[erlang-questions] "Can't set long node name" on Ubuntu using erl -name without suffix

429 views
Skip to first unread message

Daniel Dormont

unread,
Dec 9, 2011, 11:39:54 AM12/9/11
to erlang-questions
Hi everyone,

I am just now starting to get into using long node names in my Erlang
setup, running R14B02 on Ubuntu 11.10. Due to the way some of the
internal scripts for Ejabberd are written, it would be convenient if I
can start nodes using 'erl -name foo' without having to put anything
after the @ sign. On some of my machines this works fine, but on
others I get the error:


{error_logger,{{2011,12,9},{11,38,2}},"Can't set long node
name!\nPlease check your configuration\n",[]}

What does this mean and what can I do about it?

Dan
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

Wes James

unread,
Dec 9, 2011, 11:53:43 AM12/9/11
to Daniel Dormont, erlang-questions
On Fri, Dec 9, 2011 at 9:39 AM, Daniel Dormont <d...@greywallsoftware.com> wrote:
> Hi everyone,
>
> I am just now starting to get into using long node names in my Erlang
> setup, running R14B02 on Ubuntu 11.10. Due to the way some of the
> internal scripts for Ejabberd are written, it would be convenient if I
> can start nodes using 'erl -name foo' without having to put anything
> after the @ sign. On some of my machines this works fine, but on
> others I get the error:
>

You will need to use -sname with that short name and the nodes will
only be available on the same subnet.

-name requires the full node@host.

-wes

Daniel Dormont

unread,
Dec 9, 2011, 12:56:46 PM12/9/11
to Wes James, erlang-questions
On Fri, Dec 9, 2011 at 11:53 AM, Wes James <comp...@gmail.com> wrote:
> On Fri, Dec 9, 2011 at 9:39 AM, Daniel Dormont <d...@greywallsoftware.com> wrote:
>> Hi everyone,
>>
>> I am just now starting to get into using long node names in my Erlang
>> setup, running R14B02 on Ubuntu 11.10. Due to the way some of the
>> internal scripts for Ejabberd are written, it would be convenient if I
>> can start nodes using 'erl -name foo' without having to put anything
>> after the @ sign. On some of my machines this works fine, but on
>> others I get the error:
>>
>
> You will need to use -sname with that short name and the nodes will
> only be available on the same subnet.
>
> -name requires the full node@host.
>

Perhaps it's an unexpected or undocumented feature, but this is not
true. For example, on one of my Amazon EC2 machines just now I ran
'erl -name foo' and got the following:

Erlang R13B03 (erts-5.7.4) [source] [64-bit] [rq:1] [async-threads:0]
[hipe] [kernel-poll:false]

Eshell V5.7.4 (abort with ^G)
(f...@domU-xx-xx-xx-xx.compute-1.internal)1>

no issues.

Daniel Dormont

unread,
Dec 9, 2011, 2:08:26 PM12/9/11
to Wes James, erlang-questions
A little more experimentation revealed that the problem was that the
system returned no FQDN for itself, as indicated for example by
'hostname -f'. A little /etc/hosts manipulation fixed that, and all
was well.

dan

Per Hedeland

unread,
Dec 9, 2011, 6:45:35 PM12/9/11
to comp...@gmail.com, d...@greywallsoftware.com, erlang-q...@erlang.org
Daniel Dormont <d...@greywallsoftware.com> wrote:
>
>On Fri, Dec 9, 2011 at 11:53 AM, Wes James <comp...@gmail.com> wrote:
>> On Fri, Dec 9, 2011 at 9:39 AM, Daniel Dormont <d...@greywallsoftware.com> wrote:
>>> Hi everyone,
>>>
>>> I am just now starting to get into using long node names in my Erlang
>>> setup, running R14B02 on Ubuntu 11.10. Due to the way some of the
>>> internal scripts for Ejabberd are written, it would be convenient if I
>>> can start nodes using 'erl -name foo' without having to put anything
>>> after the @ sign. On some of my machines this works fine, but on
>>> others I get the error:
>>>
>>
>> You will need to use -sname with that short name and the nodes will
>> only be available on the same subnet.
>>
>> -name requires the full node@host.
>>
>
>Perhaps it's an unexpected or undocumented feature, but this is not
>true.

You are quite correct - actually the fact that you *can* give node@host
to either of -name or -sname is an undocumented (and perhaps unexpected)
feature.:-) Just Read The Fine erl(1) Man page, it is quite clear that
you are supposed to give only the 'node' part, and that the runtime
system is supposed to append the rest. But sometimes things don't work
as they are supposed to (as in your case before you fixed it), in which
case giving node@host can be a workaround.

(And of course the 'foo' in 'erl -name foo' is neither long nor short,
the length refers to the part *after* the '@'.)

--Per Hedeland

Nico Kruber

unread,
Dec 9, 2011, 8:23:28 PM12/9/11
to erlang-q...@erlang.org
Just let me point out, that 'erl -name f...@127.0.0.1' or some other IP address
of the server also works.

This can sometimes be a good alternative to the hostname.

Regards,
Nico Kruber

signature.asc

Iván Martínez

unread,
Apr 24, 2014, 7:46:10 AM4/24/14
to erlang-pr...@googlegroups.com, comp...@gmail.com, d...@greywallsoftware.com, erlang-q...@erlang.org, p...@hedeland.org
I have been fighting with this issue because my colleagues refused to specify a domain with "-name" in the project, they wanted erl to take it from the machine where it was running. It worked for them and after carefully reading the documentation, I think it is supposed to work:

<<
-name Name

Makes the Erlang runtime system into a distributed node. This flag invokes all network servers necessary for a node to become distributed. See net_kernel(3). It is also ensured that epmd runs on the current host before Erlang is started. See epmd(1).

The name of the node will be Name@Host, where Host is the fully qualified host name of the current host. For short names, use the -sname flag instead.

>>

After several tests I have learned that it doesn't work when the hostname doesn't have a ".", like if you have...

# hostname -f

laptop

...then...

# erl -name test

...won't work, but if you have...

# hostname -f

latpop.local

...then...

# erl -name test

...does work. I think it's a bug in erl, because...

# erl -name test@laptop

...always works and doesn't have a "." in the domain.

Iván
Reply all
Reply to author
Forward
0 new messages