%3F.png)
Estou executando Nginx, FCGI e Request Tracker em um servidor Debian Jessie. O Request Tracker é servido pelo Nginx, mas o FCGI fica entre eles. O importante é que o servidor FCGI às vezes falha, fazendo com que os usuários do RT vejam um erro 502. A correção é bastante simples, mas apenas porque eu fiz isso inúmeras vezes no último mês. Se eu não estiver por perto e alguém precisar reiniciar o servidor FCGI, poderá ter dificuldades. Além disso, parar e reiniciar o servidor é irritante, mas você precisa fazer isso para aplicar as alterações ao RT.
Tudo isso me leva a isso: como posso tornar os comandos mais fáceis? Um roteiro? Um serviço, então ele mora /etc/init.d? Algo mais? Sou novo no Debian e no Linux em geral, então não conheço realmente minhas opções ou o quão envolvidas cada uma pode estar. Aqui estão os comandos que você deve emitir:
netstat -antp | grep LIST | grep 12345
(Isso encontra o servidor FCGI vinculado à porta 12345, para que eu possa 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 netstatcomando não pode retornar nada. Se isso acontecer, o servidor FCGI falhou silenciosamente, então você pula o killcomando e vai direto para spawn-fcgiaquele. Caso contrário, você mantém o killcomando.
Idealmente, adoraria ter opções de iniciar/parar/reiniciar para algo como /etc/init.d/rt-fcgi-server. Não tenho ideia do que fazer para encerrar o processo, devido à necessidade de encontrar o PID primeiro. Pensei em usar um .pidarquivo, mas não sei como spawn-fcgiusar um e o que fazer com esse arquivo, mesmo que o tivesse. Nem sei se faria o que eu quero (guardar o PID para evitar usar o netstatcomando).
Espero que tudo isso faça sentido. Basicamente, quero ter um comando, ou algo vinculado /etc/init.d, para controlar o resultado do spawn-fcgicomando. Quero que usuários não-root, que sabem menos sobre Linux do que eu, possam fazer login e executar um único comando, e não me importaria de consultar o status desse processo sem usar netstat, mesmo que eu não precisa obter o PID para matá-lo. Dessa forma, posso usar algo como Monit para reiniciar automaticamente o servidor caso ele falhe.
Responder1
Vou escrever esta resposta da perspectiva do FreeBSD, mas deve ser aplicável ao Linux e Debian ... nomes de pacotes e outros enfeites podem mudar.
Fiquei igualmente descontente com o spawn-fcgi. No FreeBSD, ele possui um script rc.d, mas não obedece às regras do rc.d (não pode "reiniciar", por exemplo).
No final do manual spawn-fcgi, entretanto, ele menciona supervisão. Com algumas pesquisas 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 o escolhi. Minha versão é 1.10_1 do daemontools-encore.
No FreeBSD, um script rc.d é fornecido para o svscan. No FreeBSD, isso verifica /var/service em busca de subdiretórios e executa uma "supervisão" para cada um. Aceitei esta configuração padrão e coloquei svscan_enable="YES"/etc/rc.conf. Para Linux, não sei sobre o script rc, mas diz que /service é o diretório padrão.
Dentro de /var/service, criei rt-fcgi e dentro de rt-fcgi criei run. "executar" 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 no título de um processo. Existem outras opções. O meu se parece com:
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
... o que significa que não tenho o gnupg configurado corretamente. Parece que você pode procurar por erros e outros enfeites, a menos que configure o log para svscan.
Este é um pouco pesado para um fcgi, mas está enlatado e funciona. Ele lida com a saída do script 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 apaixonado pelo padrão WSGI do que por essa bagunça.