☰

¿Es una buena práctica crear un trabajo en segundo plano dentro de un script de inicio si el proceso no puede demonizarse por sí solo?

tag-icon • tag-icon init-script daemon
¿Es una buena práctica crear un trabajo en segundo plano dentro de un script de inicio si el proceso no puede demonizarse por sí solo?

Soy bastante nuevo en *nix y me he encontrado con la necesidad de descartar múltiples procesos, que deberían ejecutarse el 100% del tiempo. al fondo usando &.

Utilizo la siguiente línea en un script init.d para hacer esto (ejecutándolo como usuario user:

su -c 'process arg1 arg2 -w - | process2 arg1 -r - &' user

(donde -w escribe y -r lee desde STDOUT, STDIN)

Específicamente, sé que esto no es generalmente aceptable, ya que los procesos no están bien protegidos de influencias externas.

¿Es aceptable crear trabajos en segundo plano para "servicios"?

¿Debería utilizar en su lugar una tubería FIFO/con nombre para manejar la comunicación entre procesos?

Si es así, ¿debería seguir creando ambos procesos como trabajos en segundo plano? ¿Es esto estable?

Para detalles específicos, consulteeste hilo de la lista de correo.

Gracias,

Mate

Respuesta1

Específicamente, sé que esto no es generalmente aceptable, ya que los procesos no están bien protegidos de influencias externas.

¿Es aceptable crear trabajos en segundo plano para "servicios"?

Si no hay otra manera (es decir, el servicio no se bifurcará por sí solo), entonces probablemente sí. Debian start-stop-daemontiene un --backgroundparámetro para tales casos:

   -b, --background
          Typically used with programs that don't  detach  on  their  own.
          This option will force start-stop-daemon to fork before starting
          the  process,  and  force  it  into  the  background.   WARNING:
          start-stop-daemon  cannot  check  the exit status if the process
          fails to execute for any reason. This is a last resort,  and  is
          only  meant  for  programs  that either make no sense forking on
          their own, or where it's not feasible to add the code  for  them
          to do this themselves.

Respuesta2

Como la primera pregunta ya está respondida, me concentraré en las dos últimas.

Hace unos días tuve problemas con un problema similar: tuve que iniciar algunos procesos mediante una tubería desde /etc/init.dscripts. Para resolver esto, eché un vistazo a RHEL6 ( daemony killprocde /etc/init.d/functions) y Debian ( start-stop-daemon). Lo que aprendí fue que ambos no manejaban las tuberías (muy bien). Aunque de alguna manera fue posible iniciarlos, hubo grandes problemas para detenerlos. Por eso escribí una pequeña herramienta.pipexec. Este programa inicia una canalización de programas pero se comporta como un solo programa. Ejemplo: cuando se SIGTERMle envía a, pipexecmata a todos los niños y luego a sí mismo. También se admite el manejo de archivos pid, lo que le facilita la integración con RHEL6 daemony killproc.

¿Debería utilizar en su lugar una tubería FIFO/con nombre para manejar la comunicación entre procesos? Si es así, ¿debería seguir creando ambos procesos como trabajos en segundo plano? ¿Es esto estable?

También pensé en esto, pero para mí esto es demasiado complicado y no tenía muy buena experiencia en lo que respecta a estabilidad y confiabilidad con fifos (tal vez este sea mi problema, pero por eso rara vez los uso ;-))

Lo integré pipexeccon RHEL6 y no hay problemas; simplemente corre.

Saludos cordiales - Andreas

información relacionada