Alternativa ao Daemontools (djbtools) para supervisionar processos unix?

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

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

Lembro-me de que alguns daemons "supervisores / vigilantes" semelhantes estavam em andamento há cerca de dois anos, mas alguns ainda eram um pouco ásperos.

Se você mudou do Daemontools para outra coisa, o que você escolheu e funcionou bem para você? O RedHat ou Ubuntu vem com algum utilitário de supervisor de processo por padrão?

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

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

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

Uma opção final que eu ouvi falar, mas não usei, é o Supervisor . Parece uma ferramenta promissora, mas o restartd funcionou bem o suficiente para mim no passado, para o que eu precisava, que ainda não me preocupei em brincar com ela.

+1 para runit. Mais recursos e flexíveis que daemontools, compatíveis com argumentos e opções existentes daemontools. Muito arrumado.

Porém, como você mencionou, muitas ferramentas vêm com seus próprios binários de controle, apache2ctl, ejabberdctl, poundctl, collectd, etc. possível implementação. Geralmente faço um compromisso e tenho a maioria dos serviços executados sob a supervisão de runit. E os outros podem ter permissão para executar usando a maneira trivial.

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

O Fedora parece pronto para mudar para o systemd: http://0pointer.de/blog/projects/systemd.html

Como uma alternativa ao já mencionado daemonizee daemontools, existe o comando daemon do pacote libslack.

daemon é bastante configurável e se preocupa com todas as coisas tediosas do daemon, como reinicialização automática, log ou manipulação de arquivos de pid.

Há supervisord

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

É bastante configurável e se preocupa com todas as coisas tediosas do daemon, como reinicialização automática, log ou manipulação de arquivos de pid.

O Ubuntu vem com o Upstart - eu não sei muito sobre isso, mas sei que possui recursos de "supervisor". O launchd da Apple é outra opção (que o artigo da Wikipedia possui uma boa seção "veja também" que lista muitos 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", sempre faço a mesma pergunta: por que você precisa de um?

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

edit: como Chris aponta abaixo, às vezes você está completamente encurralado; nesse caso, uma tarefa cron * / 1 que procura o processo / pidfile, executa um start / restart se estiver ausente e envia os resultados em um email para o responsável desenvolvedor / gerente de produto é a sua posição de substituto.