[erlang-bugs] Deadlocking application_controller using init:stop/1, 2
Magnus Ottenklinger
magnus.ottenklinger@REDACTED
Fri Mar 6 11:58:14 CET 2015
Hey Siri,
Were you able to find a solution to the deadlocking problem?
Regards,
Magnus
Von: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] Im Auftrag von Magnus Ottenklinger
Gesendet: Freitag, 10. Oktober 2014 09:38
An: Siri Hansen
Cc: erlang-bugs@REDACTED
Betreff: Re: [erlang-bugs] Deadlocking application_controller using init:stop/1, 2
Hey Siri,
any update on this?
Regards,
Magnus
Von: Siri Hansen [mailto:erlangsiri@REDACTED]
Gesendet: Mittwoch, 10. September 2014 16:32
An: Magnus Ottenklinger
Cc: erlang-bugs@REDACTED<mailto:erlang-bugs@REDACTED>
Betreff: Re: [erlang-bugs] Deadlocking application_controller using init:stop/1, 2
Thanks for the additional information, Magnus! We will discuss this a bit more in the team before proceeding.
Regards
/siri
2014-09-09 11:38 GMT+02:00 Magnus Ottenklinger <magnus.ottenklinger@REDACTED<mailto:magnus.ottenklinger@REDACTED>>:
Hey Siri,
sorry for taking so long to reply.
Our system takes quite some time starting up (around one minute). While this is being done, multiple applications are started, each with a supervisor tree. Within those supervisor trees, processes might start other OTP applications, such as ssl.
The init:stop() is sent to the VM by our /etc/init.d script. If e.g. an error is detected during the startup phase, and we want to stop the node, the described deadlock appears, rendering the system unstoppable (in a clean way).
Regards, Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20150306/65ff3697/attachment.htm>
More information about the erlang-bugs
mailing list