No se puede iniciar la muestra de la liberación de Erlang generada con barras de refuerzo

Question

Soy un principiante con barras de refuerzo y Erlang en general. Estaba tratando de crear un lanzamiento de Erlang con barras de refuerzo de acuerdo con este tutorial: http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-pgrades y me quedé atascado en el punto de ejecutar el lanzamiento generado.

Mi sistema es Ubuntu 11.04 64bit, Erlang R14B03, instalado en fuentes.

Cuando invoco 'consola bin/somenode', recibo uno de los siguientes errores:

Exec: /home/ghik/Inz/somerel/rel/somenode/erts-5.8.4/bin/erlexec -boot /home/ghik/Inz/somerel/rel/somenode/releases/1/somenode -mode embedded -config /home/ghik/Inz/somerel/rel/somenode/etc/app.config -args_file /home/ghik/Inz/somerel/rel/somenode/etc/vm.args -- console
Root: /home/ghik/Inz/somerel/rel/somenode
{"init terminating in do_boot",{'cannot load',hipe_amd64_encode,get_files}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()

Curiosamente, cada vez que lo ejecuto, se enumera diferentes átomos en lugar de 'hipe_amd64_encode', por ejemplo: 'hipe_amd64_defuse', 'hipe_amd64_assemble', etc. Supongo que Erlang no puede cargar HIPE, pero no tengo idea de por qué IS es es tratando de cargarlo en primer lugar. La versión contiene solo una, una aplicación muy simple que depende solo del kernel y stdlib.

Por alguna razón, la barra de refuerzo genera un archivo .rel con muchas aplicaciones innecesarias:

%% rel generated at {2011,9,6} {20,5,48}
{release,{"somenode","1"},
     {erts,"5.8.4"},
     [{kernel,"2.14.4"},
      {stdlib,"1.17.4"},
      {sasl,"2.1.9.4"},
      {someapp,"1"},
      {compiler,"4.7.4",load},
      {crypto,"2.0.3",load},
      {et,"1.4.3",load},
      {gs,"1.5.13",load},
      {hipe,"3.8",load},
      {inets,"5.6",load},
      {mnesia,"4.4.19",load},
      {observer,"0.9.9",load},
      {public_key,"0.12",load},
      {runtime_tools,"1.8.5",load},
      {ssl,"4.1.5",load},
      {syntax_tools,"1.6.7.1",load},
      {tools,"2.6.6.4",load},
      {webtool,"0.8.8",load},
      {wx,"0.98.10",load}]}.

¿Por qué la lista de barras enumera muchas aplicaciones en el archivo .rel? Y evento si está bien, ¿por qué no comienza el lanzamiento?

Answer 1

En primer lugar, puede intentar ver qué falla durante el arranque de la VM agregando los argumentos init_debug a la VM:

$ erl -init_debug
{progress,preloaded}
{progress,kernel_load_completed}
{progress,modules_loaded}
{start,heart}
{start,error_logger}
{start,application_controller}
{progress,init_kernel_started}
...
{progress,applications_loaded}
{apply,{application,start_boot,[kernel,permanent]}}
{apply,{application,start_boot,[stdlib,permanent]}}
{apply,{c,erlangrc,[]}}
{progress,started}
Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.4  (abort with ^G)
1>

Usando esto, podrá ver con más detalles el tipo de interacciones que ocurren. Puede ser que las bibliotecas se estén cargadas en el orden incorrecto, no admite nativo, etc.

---

Segundo problema, el archivo REL que contiene demasiadas aplicaciones. Esto es probable que se deba al hecho de que la barra de refuerzo utiliza releños de transmisión de OT, y que se pueden cargar diferentes aplicaciones dependiendo de cómo sean el control granular que genere versiones (ver incl_cond material en los documentos). Hay algunos ejemplos para esto en el La liberación es la palabra CAPÍTULO DE APRENDIZAJE USTED ALGUNOS ERLANG:

{sys, [
 {lib_dirs, ["/home/ferd/code/learn-you-some-erlang/release/"]},
 {erts, [{mod_cond, derived}, % derived makes it pick less stuff
         {app_file, strip}]},
 {rel, "erlcount", "1.0.0", [kernel, stdlib, ppool, erlcount]},
 {boot_rel, "erlcount"},
 {relocatable, true},
 {profile, embedded}, % reduces the files included from each app
 {app_file, strip}, % reduces the size of app files if possible
 {incl_cond, exclude}, % by default, don't include apps. 'derived' is another option
 {app, stdlib, [{mod_cond, derived}, {incl_cond, include}]}, % include at the app
 {app, kernel, [{incl_cond, include}]},                      % level overrides the
 {app, ppool, [{vsn, "1.0.0"}, {incl_cond, include}]},       % exclude put earlier
 {app, erlcount, [{vsn, "1.0.0"}, {incl_cond, include}]}
]}.

Y esto debería generar lanzamientos más pequeños.

Answer 2

añadir reltool.config, la siguiente línea:

{app, hipe, [{incl_cond, exclude}]}

Answer 3

No sé la buena respuesta, pero sí sé que no podría comenzar un lanzamiento en varias versiones de CentOS con un par de núcleos diferentes, por lo que esto no es exactamente inusual. La actualización a 5.6 hizo que finalmente funcionara. Puedes ver qué oses realmente se prueban todos los días aquí:

http://www.erlang.org/doc/installation_guide/install.html#id62915

Además, podrías compilar sin Hipe, supongo.

Answer 4

Últimamente encontré esta publicación:http://mokele.co.uk/2011/07/01/rebar-release-upgrade-caveats.html

Descubre una lista de errores en barras de refuerzo, uno de ellos es la razón por la cual mi lanzamiento no pudo lanzar. También hay soluciones publicadas. Espero que se fusionen en el repositorio principal de barras lo antes posible.