On 22/06/16 03:51, Thomas Lau 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.
While there are few good portable options unless the supervised software
cooperates most operating systems offer useful tracking mechanisms. On
FreeBSD you could:
* put the supervised processes inside a named jail (secure container)
and destroy a stale jails in ./run
* put the supervised processes in a dedicated login class and pkill
all processes with said login class.
On Linux you can probably achieve the same with cgroups. Such ./run
script may not be portable but they are a lot more reliable than just
killing PIDs mentioned in potentially stale pidfiles or a blind pgrep/pkill.
The best (mostly) portable solution is to run the service under a
dedicated user and kill all processes of belonging to this user in ./run.
Received on Wed Jun 22 2016 - 12:00:53 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC