プロセスを停止/再起動する必要があるときに実行するカスタムの「停止」スクリプトrunit（runsv）が必要です。現在は単にプロセスを強制終了してから、「終了」スクリプトを実行します。しかし、私の場合、私のプロセスは動的に子プロセスを生成するので、単純killではなく、"killtree"それらを取り除くためにが必要です。それ、どうやったら出来るの？
controlrunit のオプションを使用して実行する必要があることはわかっていますが、ドキュメントを読むと、停止スクリプトの名前をどのように指定する必要があるのかがはっきりしません:(
回答:
ドキュメントから
制御パイプに送信された各制御文字cについて、runsvはまずservice / control / cが存在し、実行可能かどうかを確認します。そうである場合、コマンドを解釈する前に、サービス/制御/ cを開始し、終了するのを待ちます。プログラムが戻りコード0で終了する場合、runsvは対応するシグナルをサービスに送信しません。コマンドoは常にコマンドuと見なされます。コマンドdでは、最初にservice / control / tがチェックされ、次にservice / control / dがチェックされます。コマンドxでは、最初にservice / control / tがチェックされ、次にservice / control / xがチェックされます。オプションのログサービスの制御はカスタマイズできません。
つまりservice_name/control/X、X を作成する必要があります。Xはsv、dコマンド（down）のように、関連するコマンドをサービスに送信したときに実行される実行可能ファイルです。スクリプトがステータス0で終了する場合、サービス自体の停止は試行されません。
基本的には、実行可能なスクリプトが必要です。実行可能なスクリプトを実行し/etc/sv/<service>/control/dて、サービスを強制終了し、pidをクリーンアップします。
簡単な答えは、クリーンアップスクリプトに「service / finish」という名前を付けることです。このスクリプトは、「service / run」が終了したときに実行されます。
「service / control / ctrl_charインターフェースもあります。runsvに送信するコマンドに応じて、さまざまなアクションを実行できます。
私はドッカーのためにこの問題を自分で解決しなければなりませんでした。私はuwsgiサーバーを実行しており、コンテナーの停止時にdocker（INTではなくTERM）によって誤った信号が送信されました。
control / xファイルの考え方は、受信した信号に反応することです。私の場合t、termシグナル用に予約されているファイルであるため、終了シグナルのファイルを制御に配置します。スクリプトは実行可能でなければなりません。
#!/bin/bash
kill -INT `cat /tmp/project-master.pid`
スクリプトは、intシグナルをuwsgiプロセスに送信します。
制御スクリプトがエラーなしで終了する場合（戻りコード0）、元のシグナルはプロセスに送信されません。
したがって、私の場合、代わりにシグナルという用語を受け取り、サービスプロセスにintシグナルを送信することができました。