[erlang-questions] init:stop() not working?

Vlad Dumitrescu vladdu55@REDACTED
Mon Dec 17 15:09:57 CET 2012


Hi Fred,

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.

regards,
Vlad



On Mon, Dec 17, 2012 at 2:09 PM, Fred Hebert <mononcqc@REDACTED> wrote:

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


More information about the erlang-questions mailing list