Alternativa para Daemontools (djbtools) para supervisionar processos unix?

26

Eu usei Daemontools para fornecer uma maneira simples e confiável de supervisionar os serviços Unix em meus servidores. Funciona bem, mas requer um modo de pensar diferente ( The DJB Way ) e algumas queixas comuns são:

  • timestamps baseados em TAI64N
  • Não armazena scripts em /etc/init.d (ou (/usr/local)/etc/rc.d)
  • Nem sempre funciona com scripts como o apachectl. Alguns scripts precisam ser reescritos.

Eu lembro que alguns daemons similares de "supervisor / vigilante" estavam em andamento há cerca de dois anos, mas alguns ainda eram um pouco complicados.

Se mudou de Daemontools para outra coisa, o que escolheu e funcionou bem para si? O RedHat ou o Ubuntu vêm com todos os utilitários de supervisor de processo por padrão?

    
por Stefan Lasiewski 18.10.2010 / 23:45

9 respostas

15

Hrm, se você estiver usando o Ubuntu, o novo processo de inicialização, upstart , inclui um nível de supervisão do processo. Ele pode ser usado para iniciar e parar serviços padrão, como scripts init SysV, e também monitorar aplicativos em execução e recuperá-los se eles morrerem.

Você também pode implementar o restarter de processo de um homem pobre via inittab, dependendo de quais são suas necessidades.

Se você está procurando algo para manter um olho em um processo, para ter certeza de que está sempre em execução e reiniciá-lo quando não está, tive muita sorte com restartd . Infelizmente, a única fonte que eu conheço é o pacote Debian. No entanto, é uma aplicação muito pequena e simples, basicamente apenas um único arquivo .c e .h, com um arquivo make. Compilá-lo a partir do tarball de origem do Debian na Red Hat é trivial (eu até fiz um RPM dele no meu trabalho anterior).

Uma última opção da qual ouvi falar, mas não usada, é o Supervisor . Parece uma ferramenta promissora, mas o restartd funcionou bem o suficiente para mim no passado, pelo que eu precisava, que ainda não me preocupei em jogar com ele.

    
por 19.10.2010 / 15:30
13

+1 para runit. Mais recursos e flexibilidade que daemontools, compatíveis com argumentos e opções de daemontools existentes. Bem legal.

Mas, como você mencionou, muitas ferramentas vêm com seus próprios binários de controle, apache2ctl, ejabberdctl, poundctl, collectd etc. Embora existam hacks, às vezes é melhor ficar com as ferramentas fornecidas, principalmente quando você não tem certeza da implementação mais limpa possível. Eu costumo fazer um compromisso e ter a maioria dos serviços sob a supervisão do runit. E os outros podem ser autorizados a usar o caminho trivial.

    
por 19.10.2010 / 17:10
4

Bem, há runit . Eu não posso dizer quais são suas diferenças e semelhanças com daemontools, mas a julgar pelo site Berstein-esque, eu diria que há uma influência definida de Bernstein.

    
por 19.10.2010 / 00:31
4

Como uma alternativa aos já mencionados daemonize e daemontools , existe o comando daemon do pacote libslack. / p>

daemon é bastante configurável e se preocupa com todo o tedioso daemon, como reinicialização automática, registro ou manipulação de pidfile.

    
por 09.06.2012 / 14:42
3

O Fedora parece pronto para mudar para o systemd: link

    
por 19.10.2010 / 17:24
3

Existe também a ferramenta daemon do libslack que está escrita em C e está disponível para várias plataformas (Unix).

É bastante configurável e se preocupa com todo o tedioso daemon, como reinicialização automática, registro ou manipulação de pidfile.

    
por 09.06.2012 / 12:45
2

supervisord

    
por 19.10.2010 / 16:54
1

O Ubuntu vem com o Upstart - Eu não sei muito sobre isso, mas sei que ele tem recursos de "supervisor". O launchd da Apple é outra opção (que o artigo da Wikipedia tem uma boa seção "veja também" que lista um monte de outros também, incluindo Upstart e RunIt).

Todos eles têm seus pontos positivos e sua própria marca especial de übersuck - Sempre que alguém me pergunta sobre os programas "supervisor de processo" / "cão de guarda" eu sempre faço a mesma pergunta: por que você precisa de um?

    
por 19.10.2010 / 15:33
-3

Não há ferramentas populares / de consenso da comunidade para isso, porque todo mundo que segue esse caminho percebe que é um beco sem saída. Se seus processos de execução longa falharem com muita frequência para que o monitoramento simples seja bom o suficiente, pare de usá-los e mova seu código para dentro de algo que será mais orientado a eventos.

edit: como Chris aponta abaixo algumas vezes você está completamente encurralado, caso em que uma tarefa cron * / 1 que procura o processo / pidfile, executa um start / restart se estiver faltando, e exibe os resultados em um email para o desenvolvedor responsável / product-manager é sua posição de fallback.

    
por 19.10.2010 / 16:17