Como escrever runit script de parada personalizado

Question

Eu quero ter um script "stop" personalizado runit ( runsv ) para executar ao ter que parar / reiniciar o processo. Atualmente ele simplesmente mata o processo e executa o script "finish". Mas, no meu caso, meu processo gera processos filho dinamicamente, então, em vez de simples kill , preciso de um "killtree" para me livrar deles. Como eu faço isso?

Eu sei que isso deve ser feito através das opções control do runit, mas da leitura dos documentos não é muito claro para mim como o script de parada deve ser nomeado: (

link

    

Answer 1

A partir dos documentos

For each control character c sent to the control pipe, runsv first checks if service/control/c exists and is executable. If so, it starts service/control/c and waits for it to terminate, before interpreting the command. If the program exits with return code 0, runsv refrains from sending the service the corresponding signal. The command o is always considered as command u. On command d first service/control/t is checked, and then service/control/d. On command x first service/control/t is checked, and then service/control/x. The control of the optional log service cannot be customized.

Isso significa que você precisa criar um service_name/control/X , sendo X um executável que será executado quando você enviar o comando sv relacionado ao serviço, como o comando d (inativo). Se o seu script sair com o status 0, ele não tentará baixar o serviço em si.

Basicamente, você precisa de um script executável em /etc/sv/<service>/control/d , que fará o que quiser e matará o serviço, limpará os pids e etc.

    

Answer 2

A resposta simples é nomear seu script de limpeza "service / finish". Este script é executado quando "service / run" sai.

Existe também uma "interface service / control / ctrl_char. Ele permite que você execute ações diferentes dependendo de qual comando você envia para o runsv.

    

Answer 3

Eu mesmo tive que resolver esse problema para o docker. Eu tinha o servidor uwsgi funcionando, e foi enviado o sinal errado pelo docker (TERM em vez de INT) ao parar o container.

A ideia dos arquivos control / x é reagir a um sinal recebido. No meu caso eu colocaria um arquivo t para o sinal terminado no controle, uma vez que é o arquivo reservado para o termo sinal. O script deve ser executável.

#!/bin/bash
kill -INT 'cat /tmp/project-master.pid'

O script envia um sinal int para o processo uwsgi, que é o que eu quero.

Se o script de controle estiver saindo sem erro (código de retorno 0), o sinal original não será enviado para o processo.

Então, no meu caso, consegui receber o sinal de termo e enviar um sinal int para o processo de serviço.