La forma estándar o mejor para mantener vivo el proceso iniciado por init.d

13

Estoy buscando una forma estándar o una mejor práctica para mantener vivo un demonio iniciado por un init.dscript de shell.

O incluso mejor, ¿hay alguna manera de mantenerlo vivo directamente /etc/init.d?

Específicamente, tengo un demonio llamado dtnd con un bucle infinito que busca un proceso finalizado inesperado, si hay alguno, el demonio los despierta nuevamente. Además, utilizo la herramienta start-stop-daemon para permitir que el preceso se ejecute desde un usuario del sistema dado.

Quiero ejecutar este demonio dtnd desde el inicio. Para lograr este comportamiento, creé un script init.d que "envuelve" el archivo dtnd usando los comandos de inicio, detención y estado.

Tengo 2 preguntas que me gustaría resolver:

¿Hay alguna manera de lograr mantener vivo algún proceso del script de shell init.d ? ¿Es una práctica estándar / mejor práctica?
¿Se recomienda mantener vivo un proceso con bucle infinito? Supongo que es mejor usar algún comando como respawnpara lograr eso. ¿Es correcto?

Sé sobre la existencia del respawncomando. Creo que eso es lo que necesito, pero no entiendo el flujo de trabajo entre /etc/init.d/y /etc/init. ¿Alguien puede ayudarme?

Tenga en cuenta que no tengo ni advenedizo inittab (que sólo se me permite el uso /etc/init, /etc/init.d, crony las herramientas del sistema como start-stop-daemon. Es decir, sólo las herramientas por defecto)

¡Muchísimas gracias por su tiempo!

— Adrian Antunez
fuente

posible duplicado del script

— ewwhite

13

Debian eventualmente tendrá systemd, por lo que esta es la forma de hacerlo en un sistema Linux que usa systemd (y muchos ya lo hacen; puede considerar cambiar las distribuciones).

Systemd puede manejar mantener el servicio vivo para usted automáticamente; No se requieren otras herramientas. Simplemente asegúrese de que Restart=alwaysesté configurado en la [Service]sección del archivo de servicio .

# vi /etc/systemd/system/dtnd.service

[Service]
Restart=always
#...everything else...

También hay disponibles otras opciones para escenarios más complejos.

— Michael Hampton
fuente

2

Si bien el futuro muestra opciones más flexibles, ¿esto se ocupa del entorno / condiciones actuales? La instalación de una herramienta parece ser el camino de menor resistencia en comparación con un cambio / actualización de distribución de montacargas.

— ewwhite

@ewwhite Depende. Debian tiene systemd desde wheezy, pero no era el init predeterminado. Debería ser el valor predeterminado de jessie. Y dado que nuestro usuario aceptó la respuesta, supongo que ya estaba usando systemd por otro motivo (o tenía permiso para instalarlo).

— Michael Hampton

systemdparece descartar init.dguión y base en*.service

— yurenchen

2

En lugar de editar directamente, use el más seguro systemctl edit myservice, luego systemctl daemon-reloady reinicie myservice.

— Pablo A

@PabloBianchi Crear una anulación está bien si está anulando la unidad de un servicio existente. Si está creando una unidad desde cero, como lo hizo el OP, entonces no tiene sentido.

— Michael Hampton

3

Se podría añadir que /etc/inittabcon respawn:

d1:2345:respawn:/path/to/your/first_daemon arg1 arg2
d2:2345:respawn:/path/to/your/second_daemon arg1 arg2

Es un truco sucio, pero lo he usado con éxito en el pasado en sistemas sysv-init más antiguos.

— Dennis Kaarsemaker
fuente

Pero, ¿los demonios no suelen ejecutar setsid () y fork () para ejecutarse en segundo plano?

— symcbean

¡Gracias! Como dices, es un truco sucio pero funciona. De todos modos, prefiero el uso de systemd. Ahora sé acerca de su existencia.

— Adrian Antunez

Esto no funciona en RHEL6. La utilidad de reaparición no parece estar disponible.

— Djidiouf

2

Bueno, esa es una de las razones principales, por qué Debian se está moviendo a systemd.

sysvinit (/etc/init.d) no puede detectar si un servicio está inactivo / no responde. Esto significa que debe monitorear estos servicios y escalar si un servicio ya no hace su trabajo.

probablemente lo más fácil sería migrar a otro daemonhandler como systemd (predeterminado en RHEL7, será predeterminado en los próximos debian y ubuntu lts), upstart (predeterminado en RHEL6, Ubuntu 12.04 y 14.04), daemontools (como se mencionó, desarrollado por djb) o algo más.

hacer el trabajo de mantener vivo un servicio será PITA en sysvinit.

— janaurka
fuente

1

La mejor práctica es asegurarse de que sus demonios NO SE DETENGAN en primer lugar.

Si no lo desea, puede echar un vistazo a las herramientas demoníacas de DJB

— symcbean
fuente

3

Por supuesto, la mejor práctica es garantizar que mis demonios no se detengan. Pero hay muchas aplicaciones que siguen el enfoque if-I-stop-wake-me como apache2, mysql, samba, pulseaudio ... He estado buscando daemontools y parece un buen enfoque. Desafortunadamente, no tengo permitido instalar herramientas externas. Necesito hacerlo usando bash scripting o start-stop-daemon e init.d configs.

— Adrian Antunez

1

El enfoque estándar para mí es usar la utilidad Monit para esto.

No puedo decir por su descripción si ha escrito algo como Monit y está tratando de asegurarse de que se está ejecutando, o si necesita algo para ver el demonio que ha creado.

— ewwhite
fuente

1

Hola ewwhite, tengo que asegurarme de que mi aplicación se esté ejecutando. Desafortunadamente, no tengo permitido instalar herramientas externas. Necesito hacerlo usando bash scripting o start-stop-daemon e init.d configs.

— Adrian Antunez

2

@ AdriánAntúnez Si no puede instalar las herramientas que necesita para hacer su trabajo, debe solucionar ese problema lo antes posible.

— Michael Hampton

@ AdriánAntúnez Usted solicitó "estándar". Monit es bastante conocido / bien considerado. Usted pidió "lo mejor" ... Su restricción es más política. ¿Por qué no se le permitiría instalar software?

— ewwhite

1

No es una herramienta o dependencia innecesaria si hace lo que quieres que haga .

— ewwhite

1

@ewwhite Lo siento, quise decir evitar dependencias de herramientas externas.

— Adrian Antunez