On Sep 8, 2017 13:36, "Gandalf Corvotempesta" <gandalf.corvotempesta@xxxxxxxxx> wrote:
2017-09-08 13:21 GMT+02:00 Pavel Szalbot <pavel.szalbot@xxxxxxxxx>:IIUP, the only way to keep I/O running is to gracefully exiting glusterfsd.
> Gandalf, isn't possible server hard-crash too much? I mean if reboot
> reliably kills the VM, there is no doubt network crash or poweroff
> will as well.
No, even killall resp. SIGTERMing glusterfsd ends up with I/O errors on the client.
I did not test SIGKILL because I suppose if graceful exit is bad, SIGKILL will be as well. This assumption might be wrong. So I will test it. It would be interesting to see client to work in case of crash (SIGKILL) and not in case of graceful exit of glusterfsd.
killall should send signal 15 (SIGTERM) to the process, maybe a bug in
signal management
on gluster side? Because kernel is already telling glusterfsd to exit,
though signal 15 but glusterfsd
seems to handle this in a bad way.
a server hard-crash doesn't send any signal. I think this could be
also similiar to SIGKILL (9)
that can't be catched/ignored software side.
In other words: is this a bug in gluster's signal management (if
SIGKILL is working and SIGTERM no, i'll almost sure this is a bug in
signal management),
a engineering bug (relying only on a graceful exit [but even SIGTERM
should be threthed as graceful exit] to preserve I/O on clients) or
something else ?
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
