erlang应用脚本stop分析
erlang应用脚本stop分析
其实这篇文章的名字应该是如何安全关闭erlang应用更加科学。
erlang应用脚本生成
使用rebar工具,创建一个erlang节点后,
<pre>
./rebar create-node nodeid=hook_heroes
</pre>
然后在rel目录里面,执行打包命令
<pre>
./rebar generate
</pre>
会生成完整的应用包,目录如下:
<pre>
bin erts-6.0 lib log releases
</pre>
bin里面,有一个启动脚本名字和节点名字一样的,这里是hook_heroes
停止服务的时候,目前使用
<pre>
./hook_heroes stop
</pre>
对于hook_heroes stop分析
hook_heroes stop调用如下
<pre>
%%Tell nodetool to initiate a stop
$NODETOOL stop
ES=$?
if [ "$ES" -ne 0 ]; then
exit $ES
fi
</pre>
这里的nodetool来自
<pre>
NODETOOL="$ERTS_PATH/escript $ERTS_PATH/nodetool
</pre>
即erts包下面的nodetool脚本,传入的参数stop
nodetool是一个escript脚本,作用就是“Helper Script for interacting with live nodes”
<pre>
case RestArgs of
["getpid"] ->
io:format("~p\n",
[list_to_integer(rpc:call(TargetNode, os, getpid, []))]);
["ping"] ->
io:format("pong\n");
["stop"] ->
io:format("~p\n", [rpc:call(TargetNode, init, stop, [], 60000)]);
.......
</pre>
可以看到,直接使用的是rpc:call()方法:调用TargetNode的init模块的stop方法,传入的参数为[],下面来看看init模块的stop方法。
init模块的stop()方法调用
init 模块的文档给的解释是:“Coordination of System Startup”,
stop方法的注释是:
<pre>
All applications are taken down smoothly, all code is unloaded, and all ports are closed before the system terminates
</pre>
显然就是用来系统关闭的,关键是需要看看他是怎么关闭系统的。
函数入口:
<pre>
stop() -> init ! {stop,stop}, ok.
</pre>
给init模块发送自己发送一个{stop,stop}消息,
init自己循环接收消息
<pre>
loop(State) ->
receive
{'EXIT',Pid,Reason} ->
Kernel = State#state.kernel,
terminate(Pid,Kernel,Reason), %% If Pid is a Kernel pid, halt()!
loop(State);
{stop,Reason} ->
stop(Reason,State);
{From,fetch_loaded} -> %% The Loaded info is cleared in
Loaded = State#state.loaded, %% boot_loop but is handled here
From ! {init,Loaded}, %% anyway.
loop(State);
{From, {ensure_loaded, _}} ->
From ! {init, not_allowed},
loop(State);
Msg ->
loop(handle_msg(Msg,State))
end.
</pre>
匹配到{stop,Reason},进入stop(Reason,State)这里调用,Reason为stop,
来打这里
<pre>
stop(Reason,State) ->
BootPid = State#state.bootpid,
{_,Progress} = State#state.status,
State1 = State#state{status = {stopping, Progress}},
clear_system(BootPid,State1),
do_stop(Reason,State1).
</pre>
重点看下clear_system函数和do_stop函数
clear_system()函数
clear_system()这里的作用就是关闭虚拟机中的进程,只用三个函数调用
<pre>
clear_system(BootPid,State) ->
Heart = get_heart(State#state.kernel), %A
shutdown_pids(Heart,BootPid,State), %B
unload(Heart). %C
</pre>
A和C都是在处理erlang启动参数heart,其意义在vm.args有说明
<pre>
Heartbeat management; auto-restarts VM if it dies or becomes unresponsive
(Disabled by default..use with caution!)
-heart
</pre>
一般情况下,不使用-heart
我们这里只看shutdown_pids()怎么做的。
shutdown_pids()函数
<pre>
shutdown_pids(Heart,BootPid,State) ->
Timer = shutdown_timer(State#state.flags),
catch shutdown(State#state.kernel,BootPid,Timer,State),
kill_all_pids(Heart), % Even the shutdown timer.
kill_all_ports(Heart),
flush_timout(Timer).
</pre>
这里首先关闭定时器,然后关闭kernel进程,然后再kill其余的进程。
关闭kernel进程
<pre>
%%
%% A kernel pid must handle the special case message
%% {'EXIT',Parent,Reason} and terminate upon it!
%%
shutdown_kernel_pid(Pid, BootPid, Timer, State) ->
Pid ! {'EXIT',BootPid,shutdown},
shutdown_loop(Pid, Timer, State, []).
</pre>
什么是erlang的kernel进程?
这句话是重点: A kernel pid must handle the special case message and terminate upon it!
那么什么是kernel进程呢?
看下bin/start.script
<pre>
...
{kernelProcess,heart,{heart,start,[]}},
{kernelProcess,error_logger,{error_logger,start_link,[]}},
{kernelProcess,application_controller,
{application_controller,start,
[{application,kernel,
...
</pre>
这些带kernelProcess标签的进程都是, 特别是application!
来自http://blog.yufeng.info/archives/1411
故supervisor_tree收到的是{'EXIT',BootPid,shutdown}
kill其余的进程:
<pre>
kill_all_pids(Heart) ->
case get_pids(Heart) of
[] ->
ok;
Pids ->
kill_em(Pids),
kill_all_pids(Heart) % Continue until all are really killed.
end.
</pre>
最终跟下去,使用的是
<pre>
exit(Pid,kill)
</pre>
向各个进程发送kill消息。
supervisor terminate方法
supervisor中的terminate()方法如下:
<pre>
-spec terminate(term(), state()) -> 'ok'.
terminate(_Reason, #state{children=[Child]} = State) when ?is_simple(State) ->
terminate_dynamic_children(Child, dynamics_db(Child#child.restart_type,
State#state.dynamics),
State#state.name);
terminate(_Reason, State) ->
terminate_children(State#state.children, State#state.name).
</pre>
分为simple_one_for_one和非simple_one_for_one两种情况。
terminate_dynamic_children()方法:
<pre>
...
EStack = case Child#child.shutdown of
brutal_kill ->
?SETS:fold(fun(P, _) -> exit(P, kill) end, ok, Pids),
wait_dynamic_children(Child, Pids, Sz, undefined, EStack0);
infinity ->
?SETS:fold(fun(P, _) -> exit(P, shutdown) end, ok, Pids),
wait_dynamic_children(Child, Pids, Sz, undefined, EStack0);
Time ->
?SETS:fold(fun(P, _) -> exit(P, shutdown) end, ok, Pids),
TRef = erlang:start_timer(Time, self(), kill),
wait_dynamic_children(Child, Pids, Sz, TRef, EStack0)
end,
...
</pre>
可以看出ChildSpec中的ShowDown字段的设置对于关闭子进程的影响:
brutal_kill:发送kill消息,这个消息是不能捕捉的。即使如果worker设置了process_flag(trap_exit, true),仍然不会收到{'EXIT',_FROM,REASON}这个消息;
infinity和Time都会向监督的worker进程发送shutdown信号,这里worker做了 process_flag(trap_exit, true),自然会收到{'EXIT',_FROM,REASON}。唯一的区别是infinity会一直等待,Time会设置一个超时:如果超时过了,那么supervisor会发送kill信号,直接杀死。
根据上面的分析,不难和erlang文档中对于gen_server terminate()方法
<pre>
If the gen_server is part of a supervision tree and is ordered by its supervisor to terminate, this function will be called with Reason=shutdown if the following conditions apply:
the gen_server has been set to trap exit signals, and
the shutdown strategy as defined in the supervisor's child specification is an integer timeout value, not brutal_kill.
</pre>
supervisor何时调用terminate()方法
最后一个问题来了,supervisor何时调用terminate()方法?之前分析到,关闭kernel进程的时候,supervisor监控树进程会收到来自BootPid的{'EXIT',BootPid,shutdown}消息。我们知道supervisor实际上一个gen_server,那么去看看他的handle_info()方法好了。
<pre>
-spec handle_info(term(), state()) ->
{'noreply', state()} | {'stop', 'shutdown', state()}.
handle_info({'EXIT', Pid, Reason}, State) ->
case restart_child(Pid, Reason, State) of %重启child
{ok, State1} -> %A
{noreply, State1};
{shutdown, State1} -> %B
{stop, shutdown, State1}
end;
handle_info(Msg, State) ->
error_logger:error_msg("Supervisor received unexpected message: pn",
[Msg]),
{noreply, State}.
</pre>
这里代码显然都是handle_info child发送过来的信号,调用restart_child()。在跟踪restart_child()进去,也没有看出原因:因为传入Pid并不是Child,而是BootPid,总是会走到A分支,也就是说不会调用terminate方法。这里陷入困境。
后来翻阅了supervisor文档,发现居然没有terminate()方法的说明,再次陷入困境。
最后,想起supervisor实际上一个gen_server,应该去看看gen_server()文档对于terminate()方法地说明。
<pre>
...
Even if the gen_server is not part of a supervision tree, this function will be called if it receives an 'EXIT' message from its parent. Reason will be the same as in the 'EXIT' message.
...
</pre>
这里说明,只要gen_server收到了来自parent的'EXIT' message,terminate()方法就会调用。符合之前分析地:
<pre>
{'EXIT',BootPid,shutdown}
</pre>
至于BootPid和SuperVisor是否是parent关系,这里暂时没时间探究:不过一定会是,否则,顶层的sup一定要有人通知关闭啊,而且BootPid从命名来看,相当有可能。这里留一个坑后面填上,主要是init:start()的启动。
其它
- 之前代码中的player进程的child_spec的show_down写的是brutal_kill,这里显然写错了;那么应用关闭的时候,自然不会调用terminate方法
-
Erlang OTP之terminate 深入分析这篇文章是基于erlang 14A版本的,他建议使用one_for_one。原因很简单,erlang 14A中,supervisor的terminate()函数如下
<pre>
terminate(_Reason, State) ->
terminate_children(State#state.children, State#state.name),
ok.
</pre>
对于17版本,可以看出,这里没有处理单独simple_one_for_one的情况。因为simple_one_for_one和one_for_one的child信息在supervisor里面存储的是不一样的:前者child存储在dynamics属性,
后者存储在children属性。erlang 14A的版本只处理了children里面的child,对于simple_one_for_one的child直接没有处理。
对于这篇文章的实验,我在自己电脑上也做了实验,确实和他的结果不一致。
参考资料
- Erlang OTP之terminate 深入分析
- erlang init stop浅析
- erlang doc
- ”Erlang supervisor 极其白痴的 Bug“的澄清——这篇文章提了下什么是erlang kernelProcess进程