Como monitorar um serviço e reiniciar se parado no Linux


24

Na verdade, não tenho tanta certeza se devo usar scripts de shell ou se já existem algumas maneiras. Mas, independentemente da abordagem que usamos, eu gostaria de manter um Serviço em execução o tempo todo.

Digamos iptablescomo um exemplo. Então ..

  • Sempre que o iptablesserviço estiver stoppedou (em outras palavras) não estiver em execução, eu quero que seja started(ou restarted) .. automaticamente sempre que ele parou (ou não está em execução).
  • Em outras palavras mais simples, quero manter um serviço em funcionamento o tempo todo.

(Talvez eu possa fornecer uma frequência razoável para verificar, se a verificação em tempo real é o problema. Digamos que a cada 5 minutos)

A única maneira que eu poderia pensar é usar Shell Scripts com Cron Tab.

  • Existe alguma solução inteligente, por favor?

Obrigado!


Você não deveria fazer isso. Suponha que um serviço esteja mal configurado, o que sua estratégia alcançaria? Uma lista infinita de novos julgamentos. Em vez disso, você deve escrever um script crontab alertspara algo que não está funcionando.
MariusMatutiae

Estou curioso sobre a solução direta, para a pergunta original. E também, eu tenho um serviço que só precisa ser simplesmente restartedsempre que parou, por qualquer motivo. Não há problema em reiniciar.
夏期劇場

1
Sua própria solução sugerida é inteligente o suficiente. Se você usá-lo corretamente (saia imediatamente se o serviço já estiver em execução, alertá-lo de que o serviço foi interrompido para que você possa corrigi-lo etc.) é a maneira mais simples. Um serviço que para automaticamente é um serviço problemático; portanto, você deve corrigi-lo, mas, caso contrário, como um patch temporário, um script cron ou outro daemon super simples que dorme a maior parte do tempo, fará o trabalho perfeitamente. Existem algumas ferramentas como mmonit.com/monit mas acho que no final eles todos usam uma abordagem semelhante

@MariusMatutiae, concordo com seu ponto de vista, mas isso depende da natureza do serviço, e a maioria dos gerentes de processo recuará após várias reinicializações com falha. É perfeitamente razoável que um processo termine naturalmente e que desejemos reiniciá-lo automaticamente, por exemplo, um trabalhador que escolhe um trabalho de uma fila e termina após cada execução. Também é uma ferramenta útil para administradores de sistemas que sofrem de código de vazamento de memória sob medida - limita a vida útil de um processo e o reinicia automaticamente antes que ele fique fora de controle ...
Alex Forbes

Respostas:


25

Atualização março 2018

Esta resposta agora é bastante antiga e, desde que foi escrita, o systemd venceu a guerra do pid1 no Linux. Portanto, você provavelmente deve criar uma unidade systemd , se o systemd estiver incorporado à sua distribuição (que é a maioria deles).

A resposta abaixo é preservada para a posteridade.


A resposta monit acima é válida, mas pensei em mencionar algumas alternativas:

Vale lembrar que seu sistema operacional já resolveu o problema de gerenciamento de processos. Tradicionalmente, o Linux usa o sysvinit, que é basicamente a coleção de scripts que você vê no init.d. No entanto, é bastante idiota e não pode monitorar processos, os scripts init.d são complicados e estão sendo substituídos por um bom motivo.

Sistemas operacionais mais modernos estão começando a substituir o sysvinit, e os pioneiros são Upstart e Systemd. O Debian está se inclinando para o systemd, o Ubuntu desenvolveu e já praticamente fez a transição para o Upstart, e como o Debian Redhat / CentOS / Fedora estão se movendo para o systemd. Portanto, se você usa um sistema operacional que já substituiu o sysvinit, recomendo usar o que está embutido. Os scripts são muito mais fáceis de escrever do que os scripts init.

Eu usei runit e gosto bastante, mas o mais fácil de usar é o supervisor. Também está muito bem documentado, funciona em praticamente qualquer lugar e é empacotado em todas as principais distribuições.

Mas faça o que fizer, por favor, POR FAVOR, não use um script de shell. Há tantas coisas erradas nessa abordagem!


como fazê-lo com sysvinit?
horseyguy 26/04

12

iptablesé um péssimo exemplo, pois não é realmente um serviço ou daemon em execução, mas parte do kernel. Você realmente não pode "parar" iptables, você só pode dar uma configuração e "parar" envolve uma configuração em branco. Na verdade, tive problemas com os sistemas Linux, mas a configuração do encaminhamento de portas iptablescontinua funcionando.

De qualquer forma, um utilitário chamado monitfará o que você deseja. Se você estiver usando o Debian, está apt-get install monitfora. É um pouco complicado aprender, mas muito flexível.


3

Estamos usando este script simples para alertar e iniciar o serviço, se não estiver em execução. Você também pode adicionar mais serviços.

 file name: uptime.sh

 #!/bin/bash
 #service monitoring
 /bin/netstat -tulpn | awk '{print $4}' | awk -F: '{print $4}' | grep ^80$ > /dev/null   2>/dev/null
 a=$(echo $?)
 if test $a -ne 0
 then
 echo "http service down" | mail -s "HTTP Service DOWN and restarted now" root@localhost
 /etc/init.d/httpd start > /dev/null 2>/dev/null
 else
 sleep 0
 fi
 /bin/netstat -tulpn | awk '{print $4}' | awk -F: '{print $4}' | grep ^53$ > /dev/null   2>/dev/null
 b=$(echo $?)
 if test $b -ne 0
 then
 echo "named service down" | mail -s "DNS Service DOWN and restarted now" root@localhost
 /etc/init.d/named start > /dev/null 2>/dev/null
 else
 sleep 0
 fi

 Cron setup:
 */5 * * * * /root/uptime.sh > /dev/null 2>/dev/null

O ponto de MariusMatutiae está correto, mas fizemos um script simples para monitorar o serviço HTTPD e DNS no meu servidor, está funcionando bem. Sempre que o serviço estiver inativo, o script reiniciará o serviço e fará um alerta para nós. Se recebermos muitos alertas / e-mails sobre o serviço inativo, podemos fazer uma investigação sobre ele.
Ranjithkumar T


0

Eu sei que já faz vários anos desde que a pergunta foi feita. mas com o systemd (disponível principalmente com centos e REHL), você pode executar este comando bash com cron para verificar e reiniciar se o serviço estiver inoperante.

#!/bin/bash

service=$@
/bin/systemctl -q is-active "$service.service"
status=$?
if [ "$status" == 0 ]; then
    echo "OK"
else
    /bin/systemctl start "$service.service"
fi

salve-o no diretório bin e nomeie-o como monitor. Dê permissão de arquivo apropriada a ele. então corra como

sudo monitor redis

se você deseja verificar o serviço redis e reiniciar / iniciar, se necessário.

por último, adicione isso ao seu trabalho cron.

espero que isso ajude


0

Para adicionar à longa lista de supervisão init / svc, como um subdiretório do S6, existe um novo garoto no bloco, 66, que lida com o gerenciamento de serviços do s6 e faz logon de maneira rápida, leve e fácil de usar. Este é o link para a documentação oficial do Obarun-Linux https://web.obarun.org/software

Esta é uma FAQ de como usar este software 66 e entender o s6 http://sysdfree.wordpress.com/266

Desde seu lançamento estável, apenas um bug foi encontrado relacionado às alterações do kernel de 4.20 -> 5.0, todos os outros problemas relatados tinham a ver com pessoas aprendendo algo novo. Se o gerenciamento de serviços tivesse que se tornar mais simples do que isso, seria melhor mudar para o ms-windows (Linus proíbe). Para ver na vida real como isso funciona, basta baixar um Obarun live.iso e brincar com ele. Os serviços de instalação e seus 66 scripts os habilitam, os matam, veem seus logs, os interrompem e os iniciam (enquanto habilitados), agrupam serviços em uma árvore e fazem com que as árvores de serviço iniciem e parem juntas, têm serviços em nível de usuário separadamente do sistema. Ele faz o que o s6 faz bem e simplifica o usuário a explorar o sistema à prova de balas no s6.

Os downloads de imagens podem ser encontrados aqui: https://web.obarun.org/index.php?id=74 md5 verificar arquivos https://repo.obarun.org/iso/

Além do init e do gerenciamento de serviços, o s6 / 66 não tem nenhuma dependência de mais nada no sistema. É uma camada do sistema base, deixando o restante do software funcionando por si próprio, init / svc-mgmt cego. Todos os s6 e 66 são escritos em C e não são específicos para linux ou glibc. Os servidores da Skarnet (autores s6) estão em funcionamento há quase uma década sem muitas pausas no sistema personalizado. Atualmente, Alpine, Void e Adelie também possuem o software s6 em seus repositórios; por padrão, o Adelie o utiliza para supervisão de serviço. Void agora carrega 66 também. Não sei se e até que ponto alguém já portou s6 para xxBSD ou outros sistemas xxIX.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.