Stuff Goes Bad:Erlang In Anger

Chapter 4 Connecting to Remote Nodes


Interacting with a running server program is traditionally done in one of two ways. One is to do it through an interactive shell kept available by using a screen or tmux session that runs in the background and letting someone connect to it.
The other is to program management functions or comprehensive configuration files that can be dynamically reloaded.
The interactive session approach is usually okay for software that runs in a strict ReadEval-Print-Loop (REPL). The programmed management and configuration approach requires careful planning in whatever tasks you think you’ll need to do, and hopefully getting it right.
Pretty much all systems can try that approach, so I’ll skip it given I’m somewhat more interested in the cases where stuff is already bad and no function exists for it.


Erlang uses something closer to an "interactor" than a REPL. Basically, a regular Erlang virtual machine does not need a REPL, and will happily run byte code and stick with that, no shell needed.
However, because of how it works with concurrency and multiprocessing, and good support for distribution, it is possible to have in-software REPLs that run as arbitrary Erlang processes.
This means that, unlike a single screen session with a single shell, it’s possible to have as many Erlang shells connected and interacting with one virtual machine as you want at a time 1.
Most common usages will depend on a cookie being present on the two nodes you want to connect together2, but there are ways to do it that do not include it.
Most usages will also require the use of named nodes, and all of them will require a priori measures to make sure you can contact the node.

 Erlang使用一个近似于交互器的东西(不是REPL) 。 基本上,一个正常的Erlang虚拟机根本不需要REPL,就能愉快地运行字节代码并一直保持会话,而且不需要shell。
 这也就意味着,并不仅是使用一个屏幕的单个shell,可能同时会有很多Erlang shell与虚拟机相连接,来交互 1

[1] More details on the mechanisms at
[2] More details at or

[注1] :更多细节
[注2] :更多细节