search for: threth

...KILL (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 ?

So even killall situation eventually kills VM (I/O errors). 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. I am tempted to test this setup on DigitalOcean to eliminate possibility of my hardware/network. But if Diego is able to reproduce the "reboot crash", my doubts of

...ILL (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 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170908/85c96fa6/attachment.html>

2017-09-08 13:07 GMT+02:00 Pavel Szalbot <pavel.szalbot at gmail.com>: > OK, so killall seems to be ok after several attempts i.e. iops do not stop > on VM. Reboot caused I/O errors after maybe 20 seconds since issuing the > command. I will check the servers console during reboot to see if the VM > errors appear just after the power cycle and will try to crash the VM after >