Como tornar este conjunto de comandos (para reiniciar um servidor) mais fácil?

Question

Estou executando o Nginx, o FCGI e o Request Tracker em um servidor Debian Jessie. O Request Tracker é atendido pelo Nginx, mas o FCGI fica entre eles. O importante é que o servidor FCGI, por vezes, falha, resultando em usuários de RT vendo um erro 502. A correção é simples o suficiente, mas só porque eu fiz isso inúmeras vezes no último mês. Se eu não estiver por perto e alguém tiver que reiniciar o servidor FCGI, eles podem ter dificuldades. Além disso, parar e reiniciar o servidor é irritante, mas você precisa fazê-lo para aplicar alterações à RT.

Tudo isso me leva a isso: como posso tornar os comandos mais fáceis? Um roteiro? Um serviço, então ele mora em /etc/init.d ? Algo mais? Eu sou novo no Debian, e Linux em geral, então realmente não sei as minhas opções ou o quão envolvido cada um pode ser. Aqui estão os comandos que você deve emitir:

netstat -antp | grep LIST | grep 12345

(Isso encontra o servidor FCGI ligado à porta 12345, portanto, posso obter o PID. Digamos que nosso PID seja 8091.)

kill 8091
spawn-fcgi -u someUser -g someGroup -a 127.0.0.1 -p 12345 /opt/rt4/sbin/rt-server.fcgi

Uma observação importante aqui é que o comando netstat não pôde retornar nada. Em caso afirmativo, o servidor FCGI falhou silenciosamente, portanto, pule o comando kill e vá direto para o spawn-fcgi one. Caso contrário, você mantém o comando kill em.

Idealmente, adoraria ter opções de início / parada / reinicialização para algo como /etc/init.d/rt-fcgi-server . Eu não tenho idéia do que fazer para matar o processo, por causa da necessidade de encontrar o PID primeiro. Pensei em usar um arquivo .pid , mas não sei como dizer a spawn-fcgi para usar um e o que fazer com esse arquivo, mesmo se eu o tivesse. Eu nem sei se faria o que eu quero (manter o PID para que eu possa evitar o uso do comando netstat ).

Espero que tudo isso esteja fazendo sentido. Eu basicamente quero ter um comando, ou algo vinculado a /etc/init.d , para controlar o resultado do comando spawn-fcgi . Eu quero que usuários não-root, que saibam menos sobre o Linux do que eu, consigam fazer o login e executar um único comando, e não me importaria de uma maneira de consultar o status desse processo sem usar netstat , mesmo que eu não tenha que pegar o PID para matá-lo. Dessa forma, posso usar algo como o Monit para reiniciar automaticamente o servidor caso ele falhe.

    

Answer 1

Vou escrever esta resposta a partir de uma perspectiva do FreeBSD, mas ela deve ser aplicável ao Linux e ao Debian ... nomes de pacotes e outras coisas podem mudar.

Eu estava igualmente descontente com o spawn-fcgi. No FreeBSD, ele tem um script rc.d, mas não obedece as regras do rc.d (não pode "reiniciar" por exemplo).

A parte inferior do manual do spawn-fcgi, no entanto, menciona supervisionar. Com alguns pesquisando isso revelou "daemontools" ... No FreeBSD, havia pacotes para daemontools e daemontools-encore. O -encore parecia ser mais novo e possuía mais recursos, então eu escolhi. Minha versão é 1.10_1 do daemontools-encore.

No FreeBSD, um script rc.d é fornecido para o svscan. No FreeBSD isso faz a varredura de / var / service para subdiretórios e executa um "supervisionar" para cada um. Eu aceitei essa configuração padrão e coloque svscan_enable="YES" em /etc/rc.conf. Para Linux, eu não sei sobre o script rc, mas ele diz que / service é o diretório padrão.

Dentro de / var / service, eu criei o rt-fcgi e dentro do rt-fcgi eu criei o run. "run" contém:

#!/bin/sh

spawn-fcgi -u www -g www -s /tmp/rt.sock -n -- /usr/local/sbin/rt-server.fcgi

Obviamente, no linux, isso precisa ter o usuário e o grupo que você está usando e a localização do seu rt-server.fcgi.

O sistema svscan parece anunciar as últimas linhas de erro em um título de processo. Existem outras opções. O meu parece:

46495  -  IJ   0:00.01 /usr/local/bin/readproctitle service errors: ...tory (/var/run/rt44/data/gpg). GnuPG support has been disabled (/usr/local/lib/perl5/site_perl/RT/Config.pm:790)\n[52465] [Tue Mar  7 21:09:54 2017] [warning]: The requested port (443) does NOT match the configured WebPort (80).  Perhaps you should Set($WebPort, 443); in RT_SiteConfig.pm, otherwise your internal hyperlinks may be broken. (/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm:1328)\n

... significando que eu não configurei o gnupg corretamente. Parece que você pode procurar por erros e outras coisas, a menos que você configure o log para svscan.

Este é um pouco pesado para um fcgi, mas é enlatado e funciona. Ele lida com o script saindo por qualquer motivo, mas não gerencia um arquivo PID ou o soquete (além de criar o arquivo de soquete).

Devo dizer que estou muito mais enamorado com o padrão WSGI do que essa bagunça.