How to determining why an Erlang application is not starting?

Question

I'm trying to start an Erlang app that is failing. All I see in the shell is:

=INFO REPORT==== 7-Jan-2010::17:37:42 ===
    application: ui
    exited: {shutdown,{ui_app,start,[normal,[]]}}
    type: temporary

How can I get Erlang to give me more information as to why the application is not starting? There currently is no other output in the shell.

score 13 · Accepted Answer · answered Jan 08 '10 at 01:42

13

You could try launching the shell with more logging support:

erl -boot start_sasl

this might get give a bit more details.

answered Jan 08 '10 at 01:42

jldupont

93,734
56
203
318

If you already have an open Erlang shell then type: application:start(sasl). – Maxim Vladimirsky Jan 16 '12 at 09:58
This doesn't seem to make any difference for an application start failure. (I ran application:start(sasl) from the shell.) – goertzenator Jun 25 '13 at 16:57

legoscia · Answer 2 · 2013-06-26T10:37:47.853

There is a patch (tp/supervisor-pass-on-errors) that was included in release R16B. This patch makes exit reasons appear in application stop log messages, which thus become much more useful than the {shutdown,{ui_app,start,[normal,[]]}}-style messages we've had until now.

This is the entry in the README:

OTP-10490  == stdlib ==

    If a child process fails in its start function, then the
    error reason was earlier only reported as an error report
    from the error_handler, and supervisor:start_link would only
    return {error,shutdown}. This has been changed so the
    supervisor will now return {error,{shutdown,Reason}}, where
    Reason identifies the failing child and its error reason.
    (Thanks to Tomas Pihl)

It didn't make it into R15B03 either, but it *is* in R16B01. This change is extremely helpful. — goertzenator, Jun 25 '13 at 20:10

score 0 · Answer 3 · answered Jan 08 '10 at 18:20

0

It is a pain, but the way I do it is the old fashioned way, by writing io:format's into the start function of the application (ie the code of the module with the behaviour of application) and working out which line fails :(

Sometimes brute force and ignorance is your only man...

answered Jan 08 '10 at 18:20

Gordon Guthrie

6,252
2
27
52

Yea - I _hate_ sticking io:formats in the code just to find out where a crash is... which the Erlang stack traces would give exact line numbers for these type of things as stack traces do in other languages. – Jeremy Raymond Jan 08 '10 at 22:16
Instead of using io:format, it's better to use eunit debug macros, such as ?debugHere(), ?debugVal(Val), ?debugMsg(Msg) or ?debugFmt(String, [Arg1, Arg2, ...]). – pedromanoel Dec 21 '11 at 19:49
Well since this comment was written by me - the new release (R15B) of Erlang now has the line numbers in the stacktrace. – Gordon Guthrie Jan 01 '12 at 10:44

How to determining why an Erlang application is not starting?

3 Answers3