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 <cathe...@gmail.com> wrote: > On Tue, Jun 21, 2016 at 6:51 PM, Thomas Lau <t...@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