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

Dmitry Klionsky dm.klionsky@REDACTED
Thu Dec 13 10:16:12 CET 2012


Hi,

 >> BTW, isn't ftp in the stdlib?
No, it's inside the inets application

 >> {"init terminating in do_boot",{'cannot load',ftp,get_file}}
Maybe this will clarify things for you: 
http://stackoverflow.com/questions/10417469/could-not-start-release-with-rebar-generate-epgsql

 >> {app, ftp, [{incl_cond, exclude}]},
This won't work. The `ftp' isn't a separate application

 >> {app, inets, [{incl_cond, derived}]},
Add {app, inets, [{incl_cond, include}]}.
But better include `inets' into a YOUR_APP.app.src file like this 
http://code.google.com/p/mochiweb/source/browse/trunk/src/mochiweb.app.src


Best regards,
Dmitry

On 12/13/2012 10:28 AM, Vineet Naik wrote:
> On Thu, Dec 13, 2012 at 11:37 AM, Andrew Gopienko <gopienko@REDACTED 
> <mailto:gopienko@REDACTED>> wrote:
>
>     Make sure you have sasl dependency in your app file.
>
>       {applications, [
>                       kernel,
>                       stdlib,
>                       sasl
>                      ]},
>
>
> Thanks Andrew, that was indeed the problem why no sasl error log was 
> generated.
> After adding sasl in applications, the error logged in it is,
>
> exception exit: {undef,[{inets,start,[]},
>                             {exmpp_component,init,1},
>                             {gen_fsm,init_it,6},
> {proc_lib,init_p_do_apply,3}]}
>       in function  gen_fsm:init_it/6
>
> I had added `{app, inets, [{incl_cond, exclude}]},` in reltool.config 
> myself earlier.
> I tried removing that option out now and I am getting the following 
> error while
> starting up
>
> {"init terminating in do_boot",{'cannot load',ftp,get_file}}
>
> I was getting a series of such errors before and I could fix them by 
> excluding
> non required libraries one by one. 'inets' was excluded in order to 
> fix the error for
> 'ftp' module. But it seems exmpp code needs inets:start/0.
>
> I tried replacing it with -
>
> {app, ftp, [{incl_cond, exclude}]},
>
> and later
>
> {app, inets, [{incl_cond, derived}]},
>
> But both don't work. What is the correct way to configure this?
> BTW, isn't ftp in the stdlib? I can load ftp module from inside any 
> erlang shell
>
> Thanks,
> Vineet
>
>
>
>
>
>     2012/12/13 Vineet Naik <naikvin@REDACTED <mailto:naikvin@REDACTED>>
>
>         Hi Roman,
>
>         Thanks for replying. I have <release-bundle>/log/sasl but it's
>         empty. And there is no
>         other file/dir in log dir. Do I need to include anything in
>         code/config to make
>         it log errors to a file?
>
>         Regards,
>         Vineet
>
>         On Wed, Dec 12, 2012 at 9:27 PM, Roman Gafiyatullin
>         <r.gafiyatullin@REDACTED <mailto:r.gafiyatullin@REDACTED>> wrote:
>
>             Vineet, most probably something went wrong during startup.
>             Can anything similar to sasl-error.log be found in
>             the <release-bundle>/log/ directory?
>
>             -- 
>             RG
>
>             On Wednesday, December 12, 2012 at 6:31 pm, Vineet Naik wrote:
>
>>             Hello,
>>
>>             I am trying to package my app using rebar. `rebar
>>             generate` command runs without any
>>             problem (no errors at least). But when I try to start the
>>             console by running the script generated
>>             by rebar in bin directory, it fails with "Kernel pid
>>             terminated"
>>
>>             A huge crash_dump is also created but I am not able to
>>             gather any info from it.
>>
>>             I checked the erlang docs[1], I found this paragraph
>>             about the error
>>
>>>             "Kernel pid terminated (Who) (Exit-reason)" - The kernel
>>>             supervisor has detected a failure, usually that the
>>>             application_controller has shut down (Who =
>>>             application_controller, Why = shutdown). The application
>>>             controller may have shut down for a number of reasons,
>>>             the most usual being that the node name of the
>>>             distributed Erlang node is already in use. A complete
>>>             supervisor tree "crash" (i.e., the top supervisors have
>>>             exited) will give about the same result. This message
>>>             comes from the Erlang code and not from the virtual
>>>             machine itself. It is always due to some kind of failure
>>>             in an application, either within OTP or a "user-written"
>>>             one. Looking at the error log for your application is
>>>             probably the first step to take.
>>
>>             If I run `console_clean` command, then the console start
>>             in the correct node. Does
>>             this rule out the "Node is already in use" case above?
>>
>>             I also tried running the code from an erlang shell with
>>             the ebin dir paths of all required
>>             libs added manually to sys path and it works perfectly.
>>
>>             How can I go about debugging this?
>>
>>             [1]
>>             http://www.erlang.org/doc/apps/erts/crash_dump.html#id71973
>>
>>             Thanks,
>>             Vineet
>>
>>
>>             _______________________________________________
>>             erlang-questions mailing list
>>             erlang-questions@REDACTED
>>             <mailto:erlang-questions@REDACTED>
>>             http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
>         -- 
>         Vineet Naik
>
>
>
>         _______________________________________________
>         erlang-questions mailing list
>         erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>         http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
>
> -- 
> Vineet Naik
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions


-- 
Best regards,
Dmitry Klionsky

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121213/7e4131df/attachment.htm>


More information about the erlang-questions mailing list