我想有一个自定义的“停止”脚本runit （ runsv ）执行时，必须停止/重新启动进程。 目前它只是杀死进程，然后运行“完成”脚本。 但在我的情况下，我的过程dynamicsubprocess，所以而不是简单的kill ，我需要一个"killtree"摆脱它们。 我怎么做？
我知道它应该通过runit的control选项来完成，但从阅读文档它不是很清楚我如何命名停止脚本:(
http://smarden.org/runit/runsv.8.html
从文档
对于发送到控制pipe道的每个控制字符c，runsv首先检查service / control / c是否存在并且是可执行的。 如果是，则在解释命令之前，启动service / control / c并等待它终止。 如果程序以返回代码0退出，runsv禁止向服务发送相应的信号。 命令o总是被认为是命令u。 在命令d首先检查service / control / t，然后是service / control / d。 在命令x第一个服务/控制/吨被检查，然后服务/控制/ x。 可选日志服务的控制不能自定义。
这意味着你需要创build一个service_name/control/X ，X是一个可执行文件，当你将相关的sv命令发送到服务时，就像d命令（down）一样。 如果您的脚本以状态0退出，则不会尝试closures服务本身。
基本上你需要一个在/etc/sv/<service>/control/d上的可执行脚本，它可以做你想做的任何事情，并杀死服务，清理pid等。
简单的答案是命名您的清理脚本“服务/完成”。 该脚本在“service / run”退出时执行。
还有一个“service / control / ctrl_char接口，它允许你执行不同的操作，这取决于你发送到runsv的命令。
我不得不自己解决这个问题。 我有uwsgi服务器运行，并通过docker（TERM而不是INT）在停止容器时发送了错误的信号。
控制/ x文件的想法是对收到的信号作出反应。 在我的情况下，我会把一个t文件的终止信号进入控制，因为它是为信号保留的文件。 该脚本应该是可执行的。
#!/bin/bash kill -INT `cat /tmp/project-master.pid`
该脚本发送一个int信号到uwsgi进程，这是我想要的。
如果控制脚本没有错误退出（返回代码0），则原始信号不会被发送到进程。
所以在我的情况下，我能够收到术语信号，并发出一个int信号，而不是服务进程。