<div dir="ltr"><a href="http://review.gluster.org/14980">http://review.gluster.org/14980</a>, this is where we have all the context about why I sent out this mail. Basically the tests were failing because umount is racing with version-updation xattrop. While I fixed the test to handle that race, xavi was wondering why GF_PARENT_DOWN event didn't come. I found that in cleanup_and_exit() we don't send this event. We are only calling 'fini()'. So wondering if any one knows why this is so.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 6:37 PM, Pranith Kumar Karampuri <span dir="ltr"><<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</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">It is only calling fini() apart from that not much.<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 6:36 PM, Pranith Kumar Karampuri <span dir="ltr"><<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</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">Gah! sorry sorry, I meant to send the mail as SIGTERM. Not SIGKILL. So xavi and I were wondering why cleanup_and_exit() is not sending GF_PARENT_DOWN event.<br></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 6:24 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Does anyone know why GF_PARENT_DOWN is not triggered on SIGKILL? It will give<br>
> a chance for xlators to do any cleanup they need to do. For example ec can<br>
> complete the delayed xattrops.<br>
<br>
</span>Nothing is triggered on SIGKILL. SIGKILL is explicitly defined to terminate a<br>
process *immediately*. Among other things, this means it can not be ignored or<br>
caught, to preclude handlers doing something that might delay termination.<br>
<br>
<a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04" rel="noreferrer" target="_blank">http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04</a><br>
<br>
Since at least 4.2BSD and SVr2 (the first version of UNIX that I worked on)<br>
there have even been distinct kernel code paths to ensure special handling of<br>
SIGKILL. There's nothing we can do about SIGKILL except be prepared to deal<br>
with it the same way we'd deal with the entire machine crashing.<br>
<br>
If you mean why is there nothing we can do on a *server* in response to<br>
SIGKILL on a *client*, that's a slightly more interesting question. It's<br>
possible that the unique nature of SIGKILL puts connections into a<br>
different state than either system failure (on the more abrupt side) or<br>
clean shutdown (less abrupt). If so, we probably need to take a look at<br>
the socket/RPC code or perhaps even protocol/server to see why these<br>
connections are not being cleaned up and shut down in a timely fashion.<br>
</blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br><div data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div>