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

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Fri Feb 20 11:54:19 PST 2015


Mariano,

Have you tried to find out what other data base systems do for Centos 
shutdowns?

GemStone cannot be the only system in the world that doesn't want the 
universe to disappear seconds after it has received a SIGTERM...

You probably have already looked:)

Dale

On 2/20/15 11:40 AM, Mariano Martinez Peck via Glass wrote:
>
>
> On Fri, Feb 20, 2015 at 4:32 PM, Martin McClure 
> <martin.mcclure at gemtalksystems.com 
> <mailto:martin.mcclure at gemtalksystems.com>> wrote:
>
>     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.
>
>
> Thanks for the explanation Martin. In fact, I have experienced exactly 
> that. Most of the times, it seems the time gemstone needs to shutdown 
> cleanly is less than whatever timeout the OS waits before really 
> killing it. But a couple of times happened to me what you said, that 
> the next boot took longer and then watching the logs gemstone was 
> recovering from logs....
>
> But good to know it is safe and I don't loose transactions.
>
>     Personally, I've been steering well clear of systemd, though I may
>     have
>     to learn it eventually... Good luck with it!
>
>
> Pufff.....can you believe I am since yesterday trying to make it work? 
> This CentOS 7 changed so many things...first the firewall (now 
> firewalld rather than iptables, now systemd rather than Sys V......
> At least, I do get the stopstone called during shutdown, but it seems 
> too late because I already received the kill signal. I searched every 
> possible post and tried every single combination of systemd.... but 
> nothing worked. So I guess I will have to stay this way (I really 
> don't like to shutdown things uncleanly...but if gemstone works)..
>
> Thanks Martin,
>
>     Regards,
>
>     -Martin
>
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150220/623ac98e/attachment.html>


More information about the Glass mailing list