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.
On Fri, Jul 22, 2016 at 6:24 PM, Jeff Darcy <jda...@redhat.com> wrote: > > Does anyone know why GF_PARENT_DOWN is not triggered on SIGKILL? It will > give > > a chance for xlators to do any cleanup they need to do. For example ec > can > > complete the delayed xattrops. > > Nothing is triggered on SIGKILL. SIGKILL is explicitly defined to > terminate a > process *immediately*. Among other things, this means it can not be > ignored or > caught, to preclude handlers doing something that might delay termination. > > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04 > > Since at least 4.2BSD and SVr2 (the first version of UNIX that I worked on) > there have even been distinct kernel code paths to ensure special handling > of > SIGKILL. There's nothing we can do about SIGKILL except be prepared to > deal > with it the same way we'd deal with the entire machine crashing. > > If you mean why is there nothing we can do on a *server* in response to > SIGKILL on a *client*, that's a slightly more interesting question. It's > possible that the unique nature of SIGKILL puts connections into a > different state than either system failure (on the more abrupt side) or > clean shutdown (less abrupt). If so, we probably need to take a look at > the socket/RPC code or perhaps even protocol/server to see why these > connections are not being cleaned up and shut down in a timely fashion. > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel