Hi Fred,<div><br></div><div>Thanks for the input. We don't have an application structure, just loading modules freely. The thing is that only some of the vms get in this state, so my first reaction was that it's something nondeterministic, like hanging on some socket or something like that. But it happens deterministically enough (the same kind of instance gets zombified) to make that less probable.</div>

<div><br></div><div>regards,</div><div>Vlad</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 17, 2012 at 2:09 PM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vlad,<br>
<br>
Whenever I've had this problem in the past, it was due to someone<br>
(likely me) not putting all dependencies in the .app file of my<br>
application, most notably stdlib and kernel when using a release.<br>
<br>
The applications are started in a given order, and when calling<br>
init:stop/0-1 to shut down the VM, the application controller goes<br>
through the list in reverse and terminates and unload applications and<br>
libraries in that order.<br>
<br>
Thus if you have an app where you don't have your dependencies on stdlib<br>
and kernel set, there's a possibility one of your libraries gets loaded<br>
before them (and thus unloaded after them), if I recall correctly. That<br>
ends up being an application that is technically still running, but not<br>
actually able to run. The VM ends up looking like a zombie.<br>
<br>
That's the explanation I think I got by reading the source a bit more<br>
than a year ago. I do remember that putting both kernel and stdlib in<br>
your app dependencies and re-building the release would solve that<br>
issue.<br>
<br>
I'm not sure if it applies to your current case and have no idea what<br>
ErlIDE is doing though.<br>
<br>
Regards,<br>
Fred.<br>
<div><div class="h5"><br>
On 12/17, Vlad Dumitrescu wrote:<br>
> Hi!<br>
><br>
> I have encountered situations where the beam process keeps running after<br>
> init:stop() has been called. I can't open a remote shell to that node, so<br>
> it looks that the node is in a zombie state. When I changed the shutdown<br>
> command to use erlang:halt() instead, then the vm process died as expected.<br>
><br>
> I don't have an easy way to reproduce this, it happens for some backends<br>
> started by erlide.<br>
><br>
> Has anyone an explanation for this? Is it something worth exploring?<br>
><br>
> best regards,<br>
> Vlad<br>
<br>
</div></div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</blockquote></div><br></div>