He leído y comprendido cómo se crea un proceso de demonio, pero por todo lo que leí nunca entendí realmentepor quées necesario hacerlo.
He leído que hacemos fork - setsid - fork para evitar el proceso de obtener el control de una terminal, pero ¿qué significa esto? Si inicio un programa en segundo plano usando & (por ejemplo './script &'), ¿qué hace que la ejecución de este proceso sea diferente a si ejecutara normalmente un programa que se convierte en un demonio?
¿Significa esto simplemente que si cierro la sesión, el proceso en segundo plano se detendrá y el demonio seguirá ejecutándose? Realmente tengo problemas para entender lo de "obtener el control de una terminal".
La razón por la que esto me molesta es porque estoy trabajando en un RPi integrado en un robot y, por lo tanto, necesito hacer que los programas se inicien al arrancar. Actualmente los estoy iniciando desde rc.local con un comando como este su user -c 'python /home/user/launcher.py &' &. Nunca he tenido ningún problema con el inicio del programa al arrancar (incluso puedo ver el proceso ps -ecuando se realiza SSH al RPi), pero me gustaría saber si existe algún riesgo o si es una mala práctica.
Respuesta1
Esa es más de una pregunta, cada una podría tener respuestas largas. Brevemente
Si inicio un programa en segundo plano usando & (por ejemplo './script &'), ¿qué hace que la ejecución de este proceso sea diferente a si ejecutara normalmente un programa que se convierte en un demonio?
Al ejecutar un programa en segundo plano, ya no está controlado directamente por el terminal (no puede simplemente
^Chacerlo), pero aún puede escribir en el terminal e interferir con su trabajo. Normalmente, un demonio se separará del terminal (además de bifurcarse) y su salida/error se redirigirá a archivos.¿Significa esto simplemente que si cierro la sesión, el proceso en segundo plano se detendrá y el demonio seguirá ejecutándose?
El proceso en segundo plano podría protegerse,
nohuppero a menos que se redirija su salida, cerrar la terminal impediría que escriba, lo que produciría un error que probablemente lo detendría.Me gustaría saber si hay algún riesgo/si es una mala práctica.
Además del problema de realizar un seguimiento de la salida del programa (y de los mensajes de error), existe el problema de reiniciarlo si falla. Un script de servicio encaja en la forma en que están diseñados los demás servicios del sistema, proporcionando una forma más o menos estándar de controlar el demonio.