So what you are trying to say is that we should check PID from program side
instead of depending on runsv, correct?
On Wed, Jun 22, 2016 at 11:29 AM, Colin Booth <cathexis_at_gmail.com> wrote:
> On Tue, Jun 21, 2016 at 6:51 PM, Thomas Lau <tlau_at_tetrioncapital.com>
> wrote:
> > I am try to reproduce situation when runsv under some catastrophic
> failure,
> > when runsv got killed, it will restart, but my test daemon "memcached"
> > still running on background, eventually it will start memcached twice.
> How
> > could I avoid this from happening? Seems fault handling isn't that great
> on
> > this matter.
> >
> If runsv catches a term-inducing signal that it doesn't catch (from a
> brief look at the code that appears to be every Term-action signal
> except SIGTERM) it will exit without signalling the child. The easiest
> way to not have an issue here is to write some special routine into
> your ./run script to check for a running memcache and if it finds one
> to tell it to exit. Sadly, it looks like you have to scrape the
> process table since I can't seem to find a way to shutdown memcache
> from the control interface. If it worked, you could check if the port
> was open and then netcat a shutdown command if it was listening.
>
> Cheers!
> -Colin
>
> --
> "If the doors of perception were cleansed every thing would appear to
> man as it is, infinite. For man has closed himself up, till he sees
> all things thru' narrow chinks of his cavern."
> -- William Blake
>
--
Thomas Lau
Director of Infrastructure
Tetrion Capital Limited
Direct: +852-3976-8903
Mobile: +852-9323-9670
Address: Suite 2716, Two IFC, Central, Hong Kong
Received on Wed Jun 22 2016 - 03:45:40 UTC