Hi Ulf, <div><br></div><div>thanks a lot, this one was one of the alternatives I've been thinking about - you saved me a lot of time! </div><div>FWIW, I'm trying to use Chef and Vagrant on my Mac OS, so I'm afraid I'll not be of a much help when it comes to debugging nasty net_kernel behavior in combination with escript. </div>
<div><br></div><div>So again - thanks!</div><div>Michal </div><div><br></div><div>PS: Nonetheless, it would be really nice to know if there is an easy way to ship the original erl_call together with the release.</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Jan 3, 2013 at 10:15 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi Michal,<br>
<br>
Not sure if it helps, but here is a first draft of an escript that works roughly like erl_call.<br>
<br>
<a href="https://gist.github.com/4447248" target="_blank">https://gist.github.com/4447248</a><br>
<br>
I've had great difficulty getting the Distributed Erlang bootstrap to work nicely on MacOS (haven't tried it elsewhere). Thus, the quirky method of deleting the net_sup child and re-adding it with specified arguments (also, the call to inet_db:set_hostname/1 is absolutely necessary on my machine - I can't explain why).<br>

<br>
Some of the issues I've run into:<br>
<br>
- When calling net_kernel:start(…) from within an escript, the host name is apparently determined differently from when a %%! line with a node name is given at the top of the escript. For it to work on my laptop, I have to give a fully qualified name, which the script then splits and uses for set_hostname.<br>

<br>
- The times I was able to make it work at all with net_kernel:start(), connection took forever. After replacing it with the delete_child/start_child gymnastics, this problem went away.<br>
<br>
Anyway, if it helps anyone, have at it.<br>
<br>
OTP team - this shouldn't be so hard. Perhaps someone could take a look at the issues?<br>
<br>
BR,<br>
Ulf W<br>
<div><div class="h5"><br>
On 3 Jan 2013, at 19:23, Michał Ptaszek wrote:<br>
<br>
> Hey,<br>
><br>
> I'm running my system in the embedded mode, and trying to apply live upgrades using release_handler. Nonetheless, in order to automate the process, I would like to interface with the running Erlang node via 'erl_call' command and pass the release_handler instructions as arguments (I would love to avoid writing escripts or playing with 'erl -eval "rpc:call(...)"' mumbo-jumbo).<br>

><br>
> Unfortunately, it seems like erl_call is not included in the release package generated by rebar, and to make things worse - is not even put in the standard erlang bin/ directory. Instead, by default, it's located under $ERL_ROOT/lib/erlang/lib/erl_interface-$VERSION/bin/erl_call.<br>

><br>
> Also, trying to add erl_interface application to the released apps does not work, as erl_interface is not an OTP application (does not have .app file).<br>
><br>
> What would be the best way to make sure that the target release package contains erl_call binary? How do you usually make it accessible/available on the target system?<br>
><br>
> Thanks,<br>
> Michal<br>
</div></div>> _______________________________________________<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>
<br>
Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.<br>
<a href="http://feuerlabs.com" target="_blank">http://feuerlabs.com</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>