Supervisor: Novo recurso: `disable` /` enable`

Sim por favor!!!

: +1:

: +1:

: +1:

Quando postei isso pela primeira vez, um dos mantenedores do pacote me disse (em um e-mail privado ou comentário já excluído?):

This will be pretty difficult to implement and will be confused with the existing machinery (add and remove commands). I would rather see this done in a plugin.

Com meu conhecimento do Supervisor, pensei que poderia corrigir isso na distro principal - mas não tenho ideia de como fazer isso como um plug-in. Eu tentei, mas não parecia possível com os ganchos disponíveis.

Eu conheço a possibilidade de desativar os serviços do SMF do
Remover para desabilitar um serviço é como remover um link simbólico para os bons e velhos arquivos init.d.

A difícil solução alternativa que estou usando é o gerenciamento de servidores com dois diretórios:

• serviços-todos
• habilitado para serviços

Os arquivos de configuração reais estão em services-all, eles são simbolizados em services-enabled que é o que o supervisord lê. Esta é a mesma abordagem de como algumas distros do sistema operacional empacotam apache e nginx.

A lacuna é que você precisa desabilitar o processo no supervisor E no disco; em seguida, habilite o processo em ambos os lugares também - caso contrário, o serviço será iniciado em uma reinicialização. É muito confuso, mas funciona.

@jvanasco não é uma solução direta, mas você deve dar uma chance ao Ansible. Funciona muito bem quando você investe um pouco de tempo para escrever manuais adequados.

+1

+200

Alguma novidade nesta frente?

+1 também!

Isso pode ser facilmente implementado com a ajuda de links simbólicos, da mesma forma que os servidores http estão fazendo como apache e nginx.

Basta criar essa estrutura de pastas para oferecer suporte ao recurso.
Consulte para obter mais detalhes sobre os sites disponíveis e habilitados em https://help.ubuntu.com/lts/serverguide/httpd.html

@varunpalekar não, isso não pode ser facilmente implementado com links simbólicos como apache / nginx (que também cobri acima como uma solução provisória ruim, e muitas pessoas já fazem)

O Apache e o Nginx são controlados _totalmente_ pela presença de arquivos nos diretórios de inclusão. Se um arquivo estiver em "/ sites-enabled", ele será ativado na configuração do aplicativo. Não há sistema em processo para mudar isso - para iniciar / parar um host configurado, seria necessário editar ou criar um link simbólico para um arquivo e reiniciar o serviço.

Supervisorctl é um supervisor de processo. Colocar um arquivo de configuração em "/ sites-enabled" ou "/ sites-available" torna o serviço disponível para o Supervisor - mas o Supervisor também tem controles em processo que tratam desse serviço sendo iniciado ou interrompido ... e uma configuração pode ou não pode "iniciar automaticamente" um serviço. O próprio Supervisor não seria capaz de usar links simbólicos, porque as configurações do processo poderiam estar embutidas em um único arquivo - o que significa que um recurso como esse não funcionaria em muitas configurações in-the-wild.

O Supervisorctl simplesmente precisa persistir em um pequeno arquivo de dados (pickle, json, qualquer que seja) o nome dos itens "parados", de forma que eles não sejam iniciados automaticamente se o sistema for reinicializado.

Acho que o melhor lugar para fazer isso pode ser em um arquivo de configuração secundário chamado supervisor.status ou semelhante, que seria criado / lido no mesmo diretório do arquivo de configuração ativo.

@jvanasco Eu apenas sugiro um ajuste simples pelo qual você pode obter o que precisa.

Você pode atingir seu objetivo seguindo apenas o seguinte ponto:

1. Crie um único programa em um único arquivo, é assim que você deve estruturar seu arquivo de configuração.
2. Para ativar e desativar o serviço, crie um script para isso.
3. Para habilitar o script de serviço,

ln -s /etc/supervisor/conf-available.d/program1.conf /etc/supervisor/conf.d/program1.conf supervisorctl update

1. Para desativar o script de serviço.

rm /etc/supervisor/conf.d/program1.conf supervisorctl update

Você também pode parametrizar o script acima e mover para qualquer pasta PATH para que possa acessar de qualquer lugar

O processo acima é apenas um ajuste, ele ajudará no seu cenário. Se você quiser no próprio supervisor, solicitações de RP são bem-vindas.

@varunpalekar Por favor, leia todo o tópico, pois tudo o que você diz foi abordado.

1. Eu me ofereci para escrever um PR para isso. Um mantenedor do pacote rejeitou a proposta de um PR, dizendo que deveria ser feito como um plugin - então um pedido de PR é oficialmente "indesejável" para este recurso. Só posso implementar isso dentro da distribuição principal, não como um plugin. Esperamos que o mantenedor do pacote mude de ideia à medida que este ticket cresce.
2. Você tem experiência com o Supervisor? Você está descrevendo maneiras de linha de comando para um administrador do Linux contornar uma deficiência nos recursos necessários alterando as configurações do servidor - você não está abordando como persistir um status "inativo" durante as reinicializações. Qualquer sugestão baseada na "configuração" não é uma solução e essas "soluções alternativas" já foram apresentadas e descartadas como não aplicáveis. supervisorctl é um daemon que escuta comandos para parar / iniciar serviços, portanto, os comandos emitidos dentro desse processo de controle precisam ser persistidos. Não há garantia de que a entidade que atua como um "cliente" que inicia / interrompe o serviço gerenciado pelo Supervisor seja um "usuário do sistema" - muito menos aquele que tem o privilégio de editar os arquivos de configuração. Desativar como você sugere removeria a tarefa da lista de processos gerenciáveis.

+1

+1
Eu criei o: https://github.com/Supervisor/supervisor/issues/877 porque é um recurso crucial para o meu caso de uso. Ele foi fechado, assim como o # 591, mas, em princípio, a ideia é a mesma.

@varunpalekar
Eu acho que sua abordagem torna supervisorctl stop e supervisorctl start comandos inúteis.
Sempre que você usar stop ou start , sua configuração não estará em sincronia com o estado do processo atual.
Sim, só poderíamos usar os links simbólicos conforme você sugeriu, mas indo ainda mais fundo porque usar supervisord em primeiro lugar, talvez possamos "hackear" apenas o upstart e o systemd com algumas ferramentas bash.

A falta desse recurso me levou a procurar um novo gerenciador de processos.

Isso aconteceu duas vezes na semana passada:

• um serviço gerenciado apresenta problemas, supervisorctl stop process
• enquanto trabalha para consertar o serviço gerenciado, o sistema é reinicializado
• o serviço quebrado inicia, porque o supervisorctl não dá a mínima para o fato de eu ter desativado explicitamente o serviço

Agora também eu:

• corrompeu novamente um conjunto de dados que eu estava no meio do caminho para consertar
• de alguma forma consumiu uma fila de mensagens que não deveria ser consumida

A quantidade extra de codificação e administração necessária para oferecer suporte a essa falta de um recurso básico é substancial. Estamos migrando.

: +1:

🙏🏻

+1

@varunpalekar , parece uma boa solução por enquanto. Mas acredito que as opções "desabilitar" e "habilitar", ainda são as melhores, já que é algo bem conhecido para gerenciamento de serviços, desde gerenciadores de scripts SysV como "chkconfig" e "update-rc.d". Eu entendo que o objetivo do Supervisor é um pouco diferente (melhor do que o conceito SysV), mas na verdade fica mais fácil gerenciar os serviços do Supervisor.
Todos deram um joinha aqui para esta melhoria. Sinto-me uma espécie de dever de dar também o meu aqui :).

+1

Obrigado por todo o supervisor manter. Você é demais :)!

+1

Outro +1 meu. Algum progresso neste assunto?

+1

Supervisor bastante bizarro não tem esse recurso.

+1

+1 eu realmente preciso de tal recurso

+1

+1

+1

+1

1 Realmente precisava disso hoje. Infelizmente, esse recurso não existe

+1

+1

+1

Eu estava lendo a documentação, procurando esse recurso.

Padrão: enable=true

adicionar enable=false significa que o programa não foi iniciado.

@dlangille Não tenho certeza de onde você leu isso, mas não consigo ver qualquer menção a esse comportamento nos documentos.

Também: +1

@dlangille Não tenho certeza de onde você leu isso, mas não consigo ver qualquer menção a esse comportamento nos documentos.

Eu não sei. Não me lembro de postar isso, mas me lembro de ter lido esta edição. Eu deveria ter postado um link.

O mais próximo que consegui encontrar agora era a inicialização automática .

+1

A solução mais simples é interromper o serviço supervisord. Considera isso ruim? O supervisor deve implementar uma opção desabilitar / habilitar por processo. Como solução alternativa, obviamente não respeita nenhum processo que você queira manter em execução, mas envolve zero hacks e tende a atender às minhas necessidades de 'modo de manutenção' e é muito limpo. Sua milhagem pode variar.

+1

Eu preciso desse recurso também.

Como solução alternativa, estou fazendo o seguinte: Renomeie o arquivo .conf para algo como .conf.disable e atualize-o.
Por exemplo:

root<strong i="8">@123</strong>:/etc/supervisor/conf.d# mv supervisor-program-1.conf supervisor-program-1.conf.disable
root<strong i="9">@123</strong>:/etc/supervisor/conf.d# supervisorctl update all

supervisor-program-1: stopped
supervisor-program-1: removed process group

Também gostaria disso. Obrigado pela solução alternativa mencionada @ praditha-hidayat!

+1