<p>I use Erlang with my C++ projects quite well, and I use an escript to connect to the running node to do things like query for alive status to things like pulling or pushing data, never needed the pid file as I can just ask the system for it, plus it changes on occasion.</p>

<div class="gmail_quote">On Oct 23, 2011 8:58 PM, "Garrett Smith" <<a href="mailto:g@rre.tt">g@rre.tt</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Sam,<br>
<br>
On Sun, Oct 23, 2011 at 7:57 PM, Sam Bobroff <<a href="mailto:sam@m5net.com">sam@m5net.com</a>> wrote:<br>
> Hi Garrett & all,<br>
><br>
> About this part:<br>
><br>
>> I use run_erl to run Erlang. This doesn't plug into typical watchdog<br>
>> apps, which look for pids, but it provides a way to communicate with<br>
>> Erlang (using to_erl) without using distributed Erlang. I've used this<br>
>> technique extensively and find it robust.<br>
><br>
> I've also used run_erl and found it less than robust. I'd like to<br>
> highlight the following issues:<br>
<br>
I probably should have been more specific, since we have different<br>
interpretations of "robust".<br>
<br>
run_erl does what it claims to do without bugs (that I've<br>
encountered). It's an effective controller for Erlang processes that<br>
can obviate the need for pidfiles or distributed Erlang.<br>
<br>
> * You can specify the pipe directory but not the pipe names. This<br>
> means that if you want to run two or more emulators, you cannot tie<br>
> the pipe name (which you need in order to connect to the VM) to the<br>
> emulator. (You can give every one a different directory if you<br>
> re-write the start script but this seems like a workaround rather than<br>
> a proper feature and the next issue still causes problems...)<br>
<br>
I'm not sure what your critique here is. Surely you're point isn't<br>
merely that run_erl uses a directory to manage its files.<br>
<br>
Take a look at /var/run on any system you have handy -- you'll see<br>
that lots of applications do this.<br>
<br>
For those interested, it's trivial and safe to run multiple beam<br>
processes, each using run_erl.<br>
<br>
> * The pipes aren't cleaned up if the emulator crashes or won't start.<br>
> Even if you run only a single emulator, it may be running on<br>
> /tmp/erlang.pipe.1 or /tmp/erlang.pipe.2 or whatever, depending on<br>
> previous crashes.<br>
<br>
This another surprising issue, considering how commonplace it is to<br>
have orphaned pidfiles hanging around after a process crash.<br>
<br>
If you need to cleanup after a crash, just delete the files. If you<br>
need that automated, automate it.<br>
<br>
> * run_erl provides only a single connection. If a program or user<br>
> already has the pipe open, other connects will hang or fail. A locked<br>
> up session will therefore prevent you from establishing another<br>
> session to clean it up -- or to shut down the emulator.<br>
<br>
Not only is this not a problem, it's a benefit over pidfiles and<br>
process signals, which in themselves don't provide any control over<br>
concurrent access.<br>
<br>
And if your session is locked and you need to force your way into it,<br>
use the -F option of to_erl.<br>
<br>
> * run_erl's single session is like a shared terminal: it has a shared<br>
> input buffer and the state isn't reset or cleared between connections.<br>
> If you set up a script or program to use it to control an emulator,<br>
> what happens if someone's session (or a bug in a program) leaves an<br>
> unfinished command or term in the buffer? (What happens is that all<br>
> subsequent commands fail, that's what!)<br>
<br>
You just said this: "You know what happens when I send garbage to a<br>
file? I corrupt that file, that's what!"<br>
<br>
> * Be careful using run_erl without specifying which pipe to use. It's<br>
> default is to try each in turn until it gets a connect.<br>
<br>
I assume you mean to_erl -- run_erl requires a pipe dir.<br>
<br>
to_erl looks in /tmp by default -- I haven't seen it hunt for<br>
different locations.<br>
<br>
In any case, it's a good idea to create a directory explicitly for<br>
these files and specify it when using to_erl.<br>
<br>
> It's easy to see these problems in action. On Ubuntu (and probably on<br>
> a stock compile as well) try running "/usr/lib/erlang/bin/start" on<br>
> the command line. Here's what happens on my system for a really<br>
> trivial example:<br>
><br>
> $ /usr/lib/erlang/bin/start<br>
> $ echo $?<br>
> 0<br>
><br>
> So it has started successfully! Yay!<br>
><br>
> $ to_erl<br>
> No running Erlang on pipe /tmp/erlang.pipe.2: No such device or address<br>
><br>
> Wait, what?<br>
> Why isn't it running? Why is it erlang.pipe.2 instead of .1?<br>
><br>
> Where are the logs? Nowhere?<br>
><br>
> Of course through experience I know what kind of problems will be<br>
> happening here but good luck figuring it out if you're new to Erlang.<br>
<br>
For those new to Erlang or not, don't do this, or pay any attention to<br>
this example.<br>
<br>
Use run_erl to start the VM, as per the docs:<br>
<br>
<a href="http://www.erlang.org/doc/man/run_erl.html" target="_blank">http://www.erlang.org/doc/man/run_erl.html</a><br>
<br>
And use to_erl to connect to that process. You'll need to specify the<br>
pipe dir so to_erl knows what you want to talk to.<br>
<br>
> For fun try setting up an init script that uses to_erl to control an<br>
> emulator. Then do this:<br>
><br>
>  echo x > /tmp/erlang.pipe.1.w<br>
><br>
> And then try to use your script.<br>
<br>
Also, don't kill -9 processes that you want to keep running.<br>
<br>
> Peace,<br>
> Sam.<br>
><br>
> P.S. I still love Erlang. I'm just sayin' it "for the record" as Joe suggests.<br>
><br>
<br>
Word<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>