<div dir="ltr">Bump?<div><br></div><div>Bond of supervisor+timer with rather fresh code fails to build fault-tolerant system under unclear circumstances.</div><div><br></div><div>Was there bug in erts causing message loss or timer callback failing to be called?</div><div>May user code which does not kill the timer server affect a running supervisor in this way?</div><div>Which part of system should I watch more carefully to investigate a problem?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 12:52 AM, Danil Zagoskin <span dir="ltr"><<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello!<div><br></div><div>We have an application (well, it's some patched old ejabberd fork) running on OTP R16B (no digits after "B").</div><div><br></div><div>On one of our clusters sometimes appears a strange problem with supervisor — a child does not restart after crash (one_for_one strategy):</div><div><br></div><div>Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:16:16] [async-threads:10] [hipe] [kernel-poll:false]<br></div><div><div>(ejabberd@node01)1> f(State), f(Children), State = hd([S || {data, Data} <- lists:nth(5, element(4, sys:get_status(ejabberd_listeners))), {"State", S} <- Data]), Children = element(4, State), lists:keyfind(5223, 3, Children).</div><div>{child,{restarting,<0.17921.2571>},</div><div>       5223,</div><div>       {ejabberd_listener,start,</div><div>                          [5223,ejabberd_c2s,</div><div>                           [{access,c2s},</div><div>                            {max_stanza_size,262144},</div><div>                            {sasl_mechs,[]},</div><div>                            {non_sasl_meths,[]},</div><div>                            zlib,tls, ....]]},</div><div>       permanent,brutal_kill,worker,</div><div>       [ejabberd_listener]}</div><div><br></div><div>Inspecting supervisor code gave a way to actually restart the child — supervisor:try_again_restart/2 works well when called from REPL.</div><div>As supervisor:restart/2 code says, try_again_restart is scheduled using timer:apply_after after a failed start attempt (just where 'restarting' tag appears). So it seems like lost event in timer server.</div><div><br></div><div>Git showed no changes in this part of supervisor code since R16B to current maint branch.</div><div>There are no considerable changes in timer module either.</div><div><br></div><div>Also it's quite strange to me that other clusters (with other mods loaded but with a similar config of this supervisor) do not suffer of this problem.</div><br clear="all"><div><br></div><div>How do I avoid such problem or how can I get more information on it?</div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div></font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div>
</div>