Alternative aux Daemontools (djbtools) pour superviser les processus Unix?

J'ai utilisé Daemontools pour fournir un moyen simple et fiable de superviser les services Unix sur mes serveurs. Cela fonctionne bien, mais cela nécessite une façon de penser différente ( The DJB Way ) et certaines plaintes courantes sont:

• Horodatages basés sur TAI64N
• Ne stocke pas les scripts sous /etc/init.d (ou (/usr/local)/etc/rc.d)
• Ne fonctionne pas toujours avec des scripts comme apachectl. Certains scripts doivent être réécrits.

Je me souviens que des démons similaires "superviseur / chien de garde" étaient en préparation il y a environ deux ans, mais certains étaient encore un peu rudes sur les bords.

Si vous êtes passé de Daemontools à autre chose, qu'avez-vous choisi et est-ce que cela a bien fonctionné pour vous? RedHat ou Ubuntu sont-ils fournis avec des utilitaires de supervision de processus par défaut?

Hrm, si vous utilisez Ubuntu, leur nouveau processus init, upstart , comprend un niveau de supervision des processus. Il peut être utilisé pour votre démarrage et arrêt standard de services, les scripts d'initialisation à la SysV, et il peut également surveiller les applications en cours d'exécution et les réapparaître si elles meurent.

Vous pouvez également implémenter le redémarrage du processus d'un pauvre via inittab, en fonction de vos besoins.

Si vous recherchez principalement quelque chose pour garder un œil sur un processus, pour vous assurer qu'il est toujours en cours d'exécution, puis le redémarrer lorsqu'il ne l'est pas, j'ai eu beaucoup de chance avec restartd . Malheureusement, la seule source à ma connaissance est le paquet Debian. Cependant, il s'agit d'une application très petite et simple, essentiellement un seul fichier .c et .h, avec un fichier make. Le compiler à partir de l'archive tar source Debian sur Red Hat est trivial (j'en ai même fait un RPM lors de mon travail précédent).

Une dernière option dont j'ai entendu parler, mais que je n'ai pas utilisée, est Superviseur . Cela ressemble à un outil prometteur, mais restartd a assez bien fonctionné pour moi dans le passé, pour ce dont j'avais besoin, que je n'ai pas encore pris la peine de jouer avec.

+1 pour runit. Plus de fonctionnalités et flexible que daemontools, compatible avec les arguments et options daemontools existants. Génial.

Mais comme vous l'avez mentionné, de nombreux outils sont livrés avec leurs propres fichiers binaires de contrôle, apache2ctl, ejabberdctl, poundctl, collectd, etc. mise en œuvre possible. En général, je fais un compromis et la plupart des services sont exécutés sous la supervision de runit. Et les autres peuvent être autorisés à s'exécuter de manière triviale.

Eh bien, il y a runit . Je ne peux pas vous dire quelles sont ses différences et similitudes avec daemontools, mais à en juger par le site Web de Berstein-esque, je dirais qu'il y a une influence certaine de Bernstein.

Fedora semble sur le point de passer à systemd: http://0pointer.de/blog/projects/systemd.html

Comme alternative au déjà mentionné daemonizeet daemontools, il y a la commande daemon du paquet libslack.

daemon est assez configurable et se soucie de toutes les tâches fastidieuses du démon telles que le redémarrage automatique, la journalisation ou la gestion des fichiers pid.

Il y a supervord

Il existe également l' outil démon de libslack qui est écrit en C et disponible pour diverses plates-formes (Unix).

Il est assez configurable et prend en charge toutes les tâches fastidieuses du démon telles que le redémarrage automatique, la journalisation ou la gestion du fichier pid.

Ubuntu est livré avec Upstart - je ne sais pas grand-chose mais je sais qu'il a des capacités de "superviseur". Launchd d'Apple est une autre option (cet article de Wikipédia a une belle section "voir aussi" qui répertorie un tas d'autres aussi, y compris Upstart et RunIt).

Tous ont leurs bons points et leur propre marque spéciale de übersuck - Chaque fois que quelqu'un me pose des questions sur les programmes "superviseur de processus" / "chien de garde", je pose toujours la même question: pourquoi en avez-vous besoin?

Il n'y a pas d'outils populaires / de consensus communautaire pour cela, car tous ceux qui s'engagent dans cette voie se rendent compte que c'est une impasse. Si vos processus de longue durée échouent trop souvent pour qu'une surveillance simple soit suffisante, arrêtez de les utiliser et déplacez votre code dans quelque chose qui sera davantage piloté par les événements.

modifier: comme le souligne Chris ci-dessous, vous êtes parfois complètement coincé, auquel cas un travail cron * / 1 qui recherche le processus / fichier pid, exécute un démarrage / redémarrage s'il est manquant et envoie les résultats dans un e-mail au responsable développeur / chef de produit est votre position de repli.