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.
