<div dir="ltr">Hi Roger,<div><br></div><div>there's been a few changes in the shutdown procedure (init.erl) with the introduction of Logger in OTP-21. There are also some changes in the supervision tree of the Kernel application related to Logger. I don't know if this has anything to do with your problem, but the chances exist, of course.</div><div><br></div><div>As you say, Kernel is the last application to be taken down (it's the last element in the #state.running of application_controller), and the state you see is probably stale in the sense that all applications listed before kernel in the 'running' list should already have been terminated. From the crash dump - can you see how many processes are still alive? Are they all part of kernel, or are there more applications that did not completely terminate?</div><div><br></div><div>And if we are to look closer at the logger track - do you know which logger handlers were active? Are there any children under the logger_sup supervisor, and if so, what are their state? You mention lager above, do you know how lager and logger are connected (is lager a handler under logger, or does it run independently)?</div><div><br></div><div>If you see anything suspicious related to logger, please feel free to send me the crash dump off-list, and I'll see if I can figure out anything more.</div><div><br></div><div>Regards</div><div>/siri</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Den man. 2. jul. 2018 kl. 18:24 skrev Roger Lipscombe <<a href="mailto:roger@differentpla.net">roger@differentpla.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right, so I've done some digging. I got a crash dump and by looking at<br>
the stack trace for application_controller, I can see that it's<br>
hanging in application_controller:terminate, presumably while waiting<br>
for one of the processes to stop. The pid given is <0.893.0>. Looking<br>
a bit further up the stack trace gets me the process state (possibly<br>
stale?), which contains a bunch of applications and pids. The pid it's<br>
hanging on is 'kernel', which I'd expect to be the last (?)<br>
application to be shut down. The process state (assuming it's not<br>
stale) has a load of other applications in there with pids. There are<br>
a bunch of ours, but also others, such as runtime_tools, cowboy,<br>
amqp_client, hackney, lager, etc.<br>
<br>
Is any of this useful in finding out why it's hanging?<br>
<br>
On 2 July 2018 at 16:54, Roger Lipscombe <<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>> wrote:<br>
> This sounds similar to<br>
> <a href="http://erlang.org/pipermail/erlang-questions/2012-December/071223.html" rel="noreferrer" target="_blank">http://erlang.org/pipermail/erlang-questions/2012-December/071223.html</a>,<br>
> but it's not quite the same, as far as I can tell.<br>
><br>
> I've noticed that, at some point since upgrading from OTP-20.3 to<br>
> OTP-21.0 (along with the necessary dependency updates), my Erlang<br>
> nodes are no longer stopping at the end of our system test run.<br>
><br>
> The nodes are orchestrated by having 'erlexec' run a bash script which<br>
> uses (effectively) 'foo/bin/foo foreground &'. I'm relying on erlexec<br>
> killing the bash script and that killing the nodes. This works fine<br>
> when the nodes are using OTP-20.3, but not with OTP-21.0.<br>
><br>
> If I connect to the node, I can issue 'init:stop()', and it returns<br>
> ok, but nothing happens. If I use 'application:which_applications()',<br>
> I get a timeout.<br>
><br>
> Unlike the linked discussion, I _can_ repeatedly connect a remote<br>
> shell (using erl -remsh), but I have to resort to erlang:halt() to<br>
> stop the node. Since my system test environment relies on orderly<br>
> process group teardown to stop the nodes, that's not useful.<br>
><br>
> As I understand it, process group teardown results in SIGTERM, which<br>
> results in a call to init:stop, which should stop the node. It isn't.<br>
><br>
> How do I figure out why init:stop() isn't working?<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>