<div dir="ltr">for the record, my initial suspicions were justified. i reproduced this by adding a timer:sleep in release_handler_1 to make it easier to trigger.<div><br></div><div>it would only manifest if a supervisor exited (cleanly or otherwise) during release installation. workers restarting doesn't trigger it.<br><div><br></div><div>if anyone else has experienced noproc crashes during release upgrades, i recommend trying this patch:<br><div><br></div><div><a href="https://github.com/erlang/otp/pull/822">https://github.com/erlang/otp/pull/822</a><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 August 2015 at 17:20, Richard Jones <span dir="ltr"><<a href="mailto:rj@metabrew.com" target="_blank">rj@metabrew.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Anyone else experienced a crash like this when doing a release upgrade?<div>ie, calling release_handler:install_release, with a valid relup<br><div><br></div><div>{"init terminating in do_boot",{{badmatch,{error,{'EXIT',{noproc,{sys,get_status,[<6453.14610.13>]}}}}},[{erl_eval,expr,3,[]}]}}<br></div><div><br></div><div>I've seen this a couple of times now (erlang 17.x) when upgrading production systems under load, even with a trivial relup. No idea what that pid was.</div><div><br></div><div>I think it might be a race in release_handler_1 where it calls sys:get_status without a catch, when the process in question may have been a supervision tree that had legitimately shut down since the list of pids was fetched.</div><div><br></div><div>ie:</div><div><br></div><div><a href="https://github.com/erlang/otp/blob/OTP-17.5.6.3/lib/sasl/src/release_handler_1.erl#L589" target="_blank">https://github.com/erlang/otp/blob/OTP-17.5.6.3/lib/sasl/src/release_handler_1.erl#L589</a><br></div><div><br></div><div>which calls get_proc_state, which does:</div><div><br></div><div>{status, _, {module, _}, [_, State, _, _, _]} = sys:get_status(Proc)<br></div><div><br></div><div>I've not managed to make a test for this yet, planning to spam lots of terminate_childs to a busy supervisor while calling release_handler_1:get_supervised_procs to try and reproduce.</div><div><br></div><div>If i'm right, it would only be triggered if parts of a supervision tree are shutting down during a release_upgrade, which perhaps isn't very common, depending on how dynamic the average supervision tree is in erlang apps.</div><div><br></div><div>Any feedback appreciated before I spend more time studying release handler code :)</div><span><font color="#888888"><div><br></div><div>RJ</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div></div>
</blockquote></div><br></div></div></div></div></div>