ansaurus

Question

Answer 1

+4 A:

It's kind of broken on the mac. By default, the mac can't resolve its own shortname. Your host's name is really probably "elife.local".

If you start erl with -name FQDN, then the pings will work.

ie: you would start it with

$ erl -name [email protected]

this probably could be fixed by making the mac capable of resolving it's own short name

Here's example output from my mac. When I do -sname I get the same result as you.

The first node:

$ erl -name [email protected]
Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]

Eshell V5.7.4  (abort with ^G)
([email protected])1>

The other node:

$ erl -name [email protected]
Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]

Eshell V5.7.4  (abort with ^G)
([email protected])1> net_adm:ping([email protected]).
pong

2010-01-26 03:00:44

You're the man, this works great. Thanks.

Eli 2010-01-26 03:59:39

Answer 2

+3 A:

A simpler fix might just be editing your /etc/hosts file and make sure you have something like this line:

127.0.0.1 localhost elife

My mac works fine with shortnames, and I believe this is what did it.

Jacob 2010-01-26 03:17:10

This is the correct answer. Erlang resolves names to IP addresses just like anything else. As a general principle your `net_adm:ping` will not work if a regular icmp `ping` sent to the same name is not answered.

Zed 2010-01-26 07:32:45

aside from OSX ignores the hosts file. there's another place to set it on the mac, can't remember where.edit: at least it did originally, haven't tried under Snow Leopard

2010-01-27 12:37:55

also, setting 127.0.0.1 to resolve as your hostname will break a lot of java apps (any app that uses RMI). normally, you want your hostname to point to your "public" ip addr.

2010-01-27 12:41:27

yes, your hostname to /etc/hosts makes "-sname" works on Snow Leopard (I tried). But has the drawback for things that actually try to resolve their own hostname (ie: Java RMI)

2010-01-28 13:09:50

Answer 3

A:

For the nodes communicate with each other, both should have the same cookie. On the same box it works as it end up using the cookie from $HOME/.erlang.cookie file. If this file is not present, it create a new file and put some random cookie in it. Future shells use the same cookie. But it is always better to specify the cookie on the command line via setcookie parameter.

erl -name [email protected] -setcookie mycookie

Yogish Baliga 2010-01-26 18:12:50

It is not better to set cookie via command line argument, because other users on the same system will be able to know your cookie just viewing process list, and after that malicious user will be able to send messages to your erlang nodes. If you store cookies in the file, do not forget to set proper permissions on that file.

taro 2010-08-17 07:38:41

ansaurus

tags:

views:

answers:

Getting two erl shells to talk

related questions