Phased start behaviour on error
Steve Davis
steven.charles.davis@REDACTED
Wed Mar 24 02:21:01 CET 2010
When a start phase errors out, it leaves things in an inconsistent
state.... boiling this down to the minimum:
---
%%phased.app
{application, phased, [
{description, "Unexpected behaviour"},
{vsn, "1.0"},
{applications, [kernel, stdlib]},
{mod, {phased, []}},
{start_phases, [ {first, []}, {second, []} ]},
{env, []}
]}.
---
%% phased.erl
-module(phased).
-behaviour(application).
-export([start/2, start_phase/3, config_change/3, prep_stop/1, stop/
1]).
-behaviour(supervisor).
-export([init/1]).
start(normal, []) ->
io:format("start~n"),
supervisor:start_link({local, phased_sup}, ?MODULE, []).
start_phase(first, normal, []) ->
io:format("start_phase: first~n"),
ok;
start_phase(second, normal, []) ->
io:format("start_phase: second~n"),
{error, intentional}.
config_change(_, _, _) ->
ok.
prep_stop(State) ->
State.
stop(_State) ->
ok.
init([]) ->
{ok, {{one_for_all, 0, 1}, []}}.
---
Note that I'm intentionally failing phase 2 of the startup
process... here's the console session:
4> application:start(phased).
start
start_phase: first
start_phase: second
=INFO REPORT==== 23-Mar-2010::04:11:25 ===
application: phased
exited: {intentional,{phased,start_phase,[second,normal,[]]}}
type: temporary
{error,{intentional,{phased,start_phase,
[second,normal,[]]}}}
5> application:which_applications().
[{stdlib,"ERTS CXC 138 10","1.16.5"},
{kernel,"ERTS CXC 138 10","2.13.5"}]
6> application:start(phased).
start
=INFO REPORT==== 23-Mar-2010::04:11:49 ===
application: phased
exited: {{already_started,<0.45.0>},{phased,start,[normal,[]]}}
type: temporary
{error,{{already_started,<0.45.0>},
{phased,start,[normal,[]]}}}
7> application:stop(phased).
{error,{not_started,phased}}
8> registered().
[global_group,init,erl_prim_loader,user,error_logger,rex,
standard_error_sup,kernel_sup,global_name_server,inet_db,
file_server_2,code_server,user_drv,phased_sup,
standard_error,application_controller,kernel_safe_sup]
Note that although the application is not started, it cannot be started,
and since the sup (and, in fact, any child processes started by the sup)
are still running.
/s
More information about the erlang-bugs
mailing list