[erlang-questions] Running rebar generated release failing with Kernel pid terminated"

Loïc Hoguin essen@REDACTED
Thu Dec 13 13:54:31 CET 2012

On 12/13/2012 01:42 PM, Tuncer Ayaz wrote:
> On Thu, Dec 13, 2012 at 1:28 PM, Loic Hoguin wrote:
>> On 12/13/2012 01:14 PM, Tuncer Ayaz wrote:
>>> On Thu, Dec 13, 2012 at 12:55 PM, Loic Hoguin wrote:
>>>> The problem is probably that rebar doesn't use the default reltool
>>>> mod_cond value. So not all modules are included. Try changing it
>>>> to this:
>>>>       {mod_cond, all}
>>> For certain incorrect/incomplete app resource files you may have to
>>> use such a work around. Normally the right solution is to fix the
>>> app resource files.
>> Why change the default reltool value in the first place, though? I
>> don't get it. Also how would reltool know I need certain modules if
>> they're only used dynamically?
> The default reltool spec template you get when using 'rebar create' is
> configured to create a release that contains only what's required. I
> don't think reltool can or should know modules you load from
> unreferenced applications at runtime. If it's always the same module
> from the same application, you should specify the application in your
> app's app resource file. If this can't be done for some reason, just
> change the reltool spec accordingly. Unsurprisingly the default
> template won't work for every project and it's not supposed to.

Sure but you're contradicting people's expectations. If you could use 
rebar's releases without having to know reltool this wouldn't be a 
problem, but the reltool documentation here 
http://www.erlang.org/doc/man/reltool.html says:


   This parameter controls the module inclusion policy. It defaults to
   all which means that if an application is included (either explicitly
   or implicitly) all modules in that application will be included.

Not setting this to all by default is not only against the existing 
documentation, but also has the problematic side effect that following 
this guide https://github.com/rebar/rebar/wiki/Release-handling will 
most likely *not* create a working release. It used to, but I suppose 
the default was changed in recent months, which means that a few extra 
steps and checks are needed.

Also with dynamically used modules (e.g Module = ranch_tcp), having 
mod_cond not set to all means you need to specifically include it (or 
include everything from the application), which is yet another extra 
missing step.

The default should be to make it work, not to make it pretty and broken.

Loïc Hoguin
Erlang Cowboy
Nine Nines

More information about the erlang-questions mailing list