%3F%20Ejecutar%20como%20proceso%20en%20segundo%20plano.png)
¿Cuáles son los pasos para que el proceso se desconecte del terminal? Para eso encontré la página de manual dedaemon()
En la descripción mencionan
Si nochdir es cero, daemon() cambia el directorio de trabajo actual del proceso al directorio raíz ("/"); de lo contrario, el directorio de trabajo actual no se modifica.
Si noclose es cero, daemon() redirige la entrada estándar, la salida estándar y el error estándar a /dev/null; de lo contrario, no se realizan cambios en estos descriptores de archivos.
En realidad, estaba intentando hacer que mi código Python se ejecutara como demonio. encontré tcollector
el códigoaquí. En ese código también siguen los mismos pasos que en la descripción de daemon()
. Entonces mi pregunta es, ¿por qué deberíamos seguir esos pasos (wrtdaemonize()
en tcollector
) como
¿Por qué cambiar dir
a /
, umask
a 022
y luego llamar os.setsid()
, etc.?
Respuesta1
En realidad, hay más de lo que usted citó, pero creo que la página del manual podría ser más clara.
Si nochdir es cero,
daemon()
cambia el directorio de trabajo actual del proceso al directorio raíz (/
)
La suposición aquí es que el programa se inicia desde la línea de comando de un administrador y la idea es desasociar el demonio de lo que el administrador estaba haciendo en ese momento. Cambiar el directorio de trabajo para /
evitar que el demonio mantenga ocupado un punto de montaje. Por ejemplo, si el directorio de trabajo era /home/admin
y algún tiempo después deseaba desmontarlo /home
, el demonio lo impediría.
Si noclose es cero,
daemon()
redirige la entrada estándar, la salida estándar y el error estándar a/dev/null
;
Esto es para evitar que el demonio confunda a los usuarios escribiendo mensajes de error perdidos o similares en su terminal. Lo que probablemente debería hacer el demonio es abrir algún archivo de registro (configurado) y escribir allí lo que quiera comunicar al exterior.
(Esta función se bifurca, y si la bifurcación (2) tiene éxito, el padre llama a _exit(2), de modo que solo el niño vea más errores).
Nuevamente, para desasociarse de la sesión del shell del administrador, el programa principal regresa inmediatamente y la otra parte permanece en segundo plano, por lo que no es necesario solicitar explícitamente que el programa se inicie en segundo plano (p. ej. ./daemon &
)
Ahora, lo que la página del manual no dice explícitamente, pero implica aquí (en ERRORES):
La implementación de esta función en la biblioteca GNU C se tomó de BSD y no emplea la técnica de doble bifurcación (es decir, bifurcación(2), setsid(2), bifurcación(2)) que es necesaria para garantizar que el proceso demonio resultante no es un líder de sesión. En cambio, el demonio resultante es un líder de sesión.
daemon()
también llamasetsid()
para liberarse de la sesiónterminal de control, y por tanto de las señales enviadas por el terminal. Pero como dice la cita, esto deja la posibilidad de que si abre un dispositivo terminal, accidentalmente lo obtenga como terminal de control. Para evitar eso, algunos programas llaman a fork()
, luego setsid()
desde el hijo y luego se bifurcan nuevamente, saliendo de ambos padres para que el proceso resultante no sea un líder de sesión (el del medio es/era) y no pueda obtener una terminal de control. El programa Python al que te refieres hace exactamente eso.
Cambiar el umask
no parece estar tan relacionado con demonizar. Quizás ese programa tenga una necesidad particular.