[Glass] How bad is terminating stones by their own kill signal handler?

[Martin McClure via Glass]

On 02/20/2015 11:18 AM, Mariano Martinez Peck via Glass wrote:
> Hi guys,
> 
> We are migrating to CentOS 7 and after lots of hours I cannot have
> either a Sys V init.d or systemd script that correctly start and stop
> all my stones and gems...... I have to give up. Cannot loose more
> time... (I even opened this
> http://serverfault.com/questions/670176/centos7-systemctl-calling-execstop-on-reboot-after-my-procceses-are-already-kill)
> 
> The start side is working correct. So I wonder...is it risky not to
> explicitly shutdown stone using shutdown method? I see kill signal is
> captured correctly and the stone still seems to be doing its sutff
> correct. But I wonder, is this assumption 100% safe?  I ask regarding:
> 
> 1) I don't want to manually have to start processes in the next boot ,
> neither manually or even worst using -R or .. whatever... in other
> words, I want that the stone starts up without any human action. 
> 
> 2) Of course, I don't want to loose transactions.
> 
> Thanks in advance and sorry for the bad mood....

Hi Mariano,

Killing the stone with SIGTERM (the default for the kill command) is
generally safe. But there are things to watch out for. For example,
Linux systems I've worked with often send SIGTERM to running processes
at shutdown, wait a short time (a second or so, in some cases) then send
SIGKILL (kill -9) to anything still running.

If the stone has not completed an orderly shutdown at the time that
SIGKILL is received, the next startup will be unclean and startup will
recover from transaction logs and will take longer. But you shouldn't
lose any transactions.

Personally, I've been steering well clear of systemd, though I may have
to learn it eventually... Good luck with it!

Regards,

-Martin