[erlang-questions] Erlang newbie questions

[Garrett Smith]

Hi Sam,

On Sun, Oct 23, 2011 at 7:57 PM, Sam Bobroff <sam@REDACTED> wrote:
> Hi Garrett & all,
>
> About this part:
>
>> I use run_erl to run Erlang. This doesn't plug into typical watchdog
>> apps, which look for pids, but it provides a way to communicate with
>> Erlang (using to_erl) without using distributed Erlang. I've used this
>> technique extensively and find it robust.
>
> I've also used run_erl and found it less than robust. I'd like to
> highlight the following issues:

I probably should have been more specific, since we have different
interpretations of "robust".

run_erl does what it claims to do without bugs (that I've
encountered). It's an effective controller for Erlang processes that
can obviate the need for pidfiles or distributed Erlang.

> * You can specify the pipe directory but not the pipe names. This
> means that if you want to run two or more emulators, you cannot tie
> the pipe name (which you need in order to connect to the VM) to the
> emulator. (You can give every one a different directory if you
> re-write the start script but this seems like a workaround rather than
> a proper feature and the next issue still causes problems...)

I'm not sure what your critique here is. Surely you're point isn't
merely that run_erl uses a directory to manage its files.

Take a look at /var/run on any system you have handy -- you'll see
that lots of applications do this.

For those interested, it's trivial and safe to run multiple beam
processes, each using run_erl.

> * The pipes aren't cleaned up if the emulator crashes or won't start.
> Even if you run only a single emulator, it may be running on
> /tmp/erlang.pipe.1 or /tmp/erlang.pipe.2 or whatever, depending on
> previous crashes.

This another surprising issue, considering how commonplace it is to
have orphaned pidfiles hanging around after a process crash.

If you need to cleanup after a crash, just delete the files. If you
need that automated, automate it.

> * run_erl provides only a single connection. If a program or user
> already has the pipe open, other connects will hang or fail. A locked
> up session will therefore prevent you from establishing another
> session to clean it up -- or to shut down the emulator.

Not only is this not a problem, it's a benefit over pidfiles and
process signals, which in themselves don't provide any control over
concurrent access.

And if your session is locked and you need to force your way into it,
use the -F option of to_erl.

> * run_erl's single session is like a shared terminal: it has a shared
> input buffer and the state isn't reset or cleared between connections.
> If you set up a script or program to use it to control an emulator,
> what happens if someone's session (or a bug in a program) leaves an
> unfinished command or term in the buffer? (What happens is that all
> subsequent commands fail, that's what!)

You just said this: "You know what happens when I send garbage to a
file? I corrupt that file, that's what!"

> * Be careful using run_erl without specifying which pipe to use. It's
> default is to try each in turn until it gets a connect.

I assume you mean to_erl -- run_erl requires a pipe dir.

to_erl looks in /tmp by default -- I haven't seen it hunt for
different locations.

In any case, it's a good idea to create a directory explicitly for
these files and specify it when using to_erl.

> It's easy to see these problems in action. On Ubuntu (and probably on
> a stock compile as well) try running "/usr/lib/erlang/bin/start" on
> the command line. Here's what happens on my system for a really
> trivial example:
>
> $ /usr/lib/erlang/bin/start
> $ echo $?
> 0
>
> So it has started successfully! Yay!
>
> $ to_erl
> No running Erlang on pipe /tmp/erlang.pipe.2: No such device or address
>
> Wait, what?
> Why isn't it running? Why is it erlang.pipe.2 instead of .1?
>
> Where are the logs? Nowhere?
>
> Of course through experience I know what kind of problems will be
> happening here but good luck figuring it out if you're new to Erlang.

For those new to Erlang or not, don't do this, or pay any attention to
this example.

Use run_erl to start the VM, as per the docs:

http://www.erlang.org/doc/man/run_erl.html

And use to_erl to connect to that process. You'll need to specify the
pipe dir so to_erl knows what you want to talk to.

> For fun try setting up an init script that uses to_erl to control an
> emulator. Then do this:
>
>  echo x > /tmp/erlang.pipe.1.w
>
> And then try to use your script.

Also, don't kill -9 processes that you want to keep running.

> Peace,
> Sam.
>
> P.S. I still love Erlang. I'm just sayin' it "for the record" as Joe suggests.
>

Word