
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Sent from my iPad</div><div><br>On 17/12/2015, at 21:33, Lukas Larsson <<a href="mailto:garazdawi@gmail.com">garazdawi@gmail.com</a>> wrote:<br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">Looking a bit more on the internet i found this: <a href="https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/">https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/</a> which seems to describe exactly the problem that you are experiencing. The erlang vm is not built to run as the pid 1 process, even with my new changes in the master branch this will still be a problem as instead of missing out on exit_status messages you will have a system full of zombie processes.</div></div>

</blockquote><br><div>I understand that orphaned processes will be left as zombies, but that is a more explicit problem. You list the processes and see them. The Beam VM being stuck forever because the message we know we should have received is lost is a much more confusing situation and it took a few people before we even realized what the problem was. There are several reports in the wild of strange lock ups when compiling Elixir code, for example, that I think are related to this. So, in conclusion, it would be nice if the VM simply discarded unknown SIGCHLDS that it happens to waitpid() upon without discarding the correct SIGCHLD and sending the expected exit_status message.</div><div><br></div><div>André</div></body></html>