<div dir="ltr"><p dir="ltr">Hi,</p><p dir="ltr">It's not a distributed application. <br></p><p dir="ltr">Release handler is called from another script, as part of the deployment process.</p><p dir="ltr">It runs "erl -name <a href="mailto:deployer@127.0.0.1">deployer@127.0.0.1</a> -setcookie .. " and then does rpc:call(TargetNode, release_handler, ....)</p><p><br></p><p>RJ</p><p><br></p><p dir="ltr">On 24 Aug 2015 21:55, "Éric Pailleau" <<a href="mailto:eric.pailleau@wanadoo.fr" target="_blank">eric.pailleau@wanadoo.fr</a>> wrote:<br></p><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Pid not beginning with 0 is not a local Pid.<br>
Is your release upgradeing a distributed application ?<br>
<br>
<br>
Le 24 août 2015 18:20, Richard Jones <<a href="mailto:rj@metabrew.com" target="_blank">rj@metabrew.com</a>> a écrit :<br>
><br>
> Anyone else experienced a crash like this when doing a release upgrade?<br>
> ie, calling release_handler:install_release, with a valid relup<br>
><br>
> {"init terminating in do_boot",{{badmatch,{error,{'EXIT',{noproc,{sys,get_status,[<6453.14610.13>]}}}}},[{erl_eval,expr,3,[]}]}}<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> ie:<br>
><br>
> <a href="https://github.com/erlang/otp/blob/OTP-17.5.6.3/lib/sasl/src/release_handler_1.erl#L589" rel="noreferrer" target="_blank">https://github.com/erlang/otp/blob/OTP-17.5.6.3/lib/sasl/src/release_handler_1.erl#L589</a><br>
><br>
> which calls get_proc_state, which does:<br>
><br>
> {status, _, {module, _}, [_, State, _, _, _]} = sys:get_status(Proc)<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Any feedback appreciated before I spend more time studying release handler code :)<br>
><br>
> RJ<br>
><br>
><br>
><br>
><br>
><br>
</blockquote></div>
</div>