[erlang-questions] Including erl_call in the release tarball

[Michał Ptaszek]

Hi Ulf,

thanks a lot, this one was one of the alternatives I've been thinking about
- you saved me a lot of time!
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.

So again - thanks!
Michal

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.


On Thu, Jan 3, 2013 at 10:15 PM, Ulf Wiger <ulf@REDACTED> wrote:

>
> Hi Michal,
>
> Not sure if it helps, but here is a first draft of an escript that works
> roughly like erl_call.
>
> https://gist.github.com/4447248
>
> 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).
>
> Some of the issues I've run into:
>
> - 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.
>
> - 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.
>
> Anyway, if it helps anyone, have at it.
>
> OTP team - this shouldn't be so hard. Perhaps someone could take a look at
> the issues?
>
> BR,
> Ulf W
>
> On 3 Jan 2013, at 19:23, Michał Ptaszek wrote:
>
> > Hey,
> >
> > 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).
> >
> > 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.
> >
> > 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).
> >
> > 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?
> >
> > Thanks,
> > Michal
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130104/027f4661/attachment.htm>