¿Alternativa a Daemontools (djbtools) para supervisar procesos unix?

He usado Daemontools para proporcionar una forma simple y confiable de supervisar los servicios de Unix en mis servidores. Funciona bien, pero requiere una forma diferente de pensar ( The DJB Way ) y algunas quejas comunes son:

• Marcas de tiempo basadas en TAI64N
• No almacena scripts en /etc/init.d (o (/usr/local)/etc/rc.d)
• No siempre funciona con scripts como apachectl. Algunas secuencias de comandos deben reescribirse.

Recuerdo que algunos demonios similares de "supervisor / vigilante" estaban en proceso hace unos dos años, pero algunos todavía eran un poco difíciles.

Si ha cambiado de Daemontools a otra cosa, ¿qué eligió y funcionó bien para usted? ¿RedHat o Ubuntu vienen con alguna utilidad de supervisión de procesos por defecto?

Hrm, si estás usando Ubuntu, su nuevo proceso de inicio, advenedizo , incluye un nivel de supervisión del proceso. Se puede usar para el inicio y la detención estándar de los servicios, a los scripts de inicio de SysV, y también puede monitorear las aplicaciones en ejecución y reaparecerlas si mueren.

También puede implementar el reiniciador de procesos de un hombre pobre a través de inittab, dependiendo de cuáles sean sus necesidades.

Si está buscando principalmente algo para vigilar un proceso, para asegurarse de que siempre esté ejecutándose y luego reiniciarlo cuando no lo está, he tenido mucha suerte con el reinicio . Desafortunadamente, la única fuente que conozco es el paquete Debian. Sin embargo, es una aplicación muy pequeña y simple, básicamente solo un archivo .c y .h, con un archivo make. Compilarlo desde el tarball fuente de Debian en Red Hat es trivial (incluso hice un RPM en mi trabajo anterior).

Una última opción de la que he oído hablar, pero no la uso, es Supervisor . Parece una herramienta prometedora, pero reiniciar me ha funcionado lo suficientemente bien en el pasado, por lo que necesitaba, que todavía no me he molestado en jugar con ella.

+1 para runit. Más funciones y flexibilidad que daemontools, compatible con los argumentos y opciones de daemontools existentes. Con buena pinta.

Pero como mencionó, muchas herramientas vienen con sus propios binarios de control, apache2ctl, ejabberdctl, poundctl, collectd, etc. Y aunque existen hacks, a veces es mejor quedarse con las herramientas suministradas, principalmente cuando no está seguro de lo más limpio posible implementación Normalmente hago un compromiso y la mayoría de los servicios se ejecutan bajo la supervisión de runit. Y se puede permitir que los demás corran de manera trivial.

Bueno, hay runit . No puedo decirte cuáles son sus diferencias y similitudes con Daemontools, pero a juzgar por el sitio web Berstein-esque, diría que existe una influencia definitiva de Bernstein.

Fedora parece lista para cambiar a systemd: http://0pointer.de/blog/projects/systemd.html

Como alternativa al ya mencionado daemonizey daemontools, existe el comando daemon del paquete libslack.

daemon es bastante configurable y se preocupa por todas las tediosas cosas del demonio, como el reinicio automático, el registro o el manejo de archivos pid.

Hay supervisor

También hay una herramienta de demonio de libslack que está escrita en C y disponible para varias plataformas (Unix).

Es bastante configurable y se preocupa por todas las tediosas cosas del demonio, como el reinicio automático, el registro o el manejo de archivos pid.

Ubuntu viene con Upstart : no sé mucho al respecto, pero sé que tiene capacidades de "supervisor". El lanzamiento de Apple es otra opción (ese artículo de Wikipedia tiene una buena sección de "ver también" que enumera muchos otros, incluidos Upstart y RunIt).

Todos ellos tienen sus puntos buenos y su propia marca especial de übersuck. Siempre que alguien me pregunta sobre los programas de "supervisor de procesos" / "perro guardián", siempre hago la misma pregunta: ¿Por qué necesita uno?

No hay herramientas populares / de consenso comunitario para esto porque todos los que siguen este camino se dan cuenta de que es un callejón sin salida. Si sus procesos de larga ejecución fallan con demasiada frecuencia para que el monitoreo simple sea lo suficientemente bueno, deje de usarlos y mueva su código dentro de algo que estará más impulsado por eventos.

editar: como Chris señala a continuación, a veces estás completamente acorralado, en cuyo caso un trabajo cron * / 1 que busca el proceso / pidfile, ejecuta un inicio / reinicio si falta, y envía los resultados en un correo electrónico al responsable desarrollador / gerente de producto es su posición alternativa.