Un proceso no se "mata con SIGHUP", al menos, no en el sentido estricto de la palabra. Más bien, cuando se interrumpe la conexión, el proceso de control de la terminal (en este caso, Bash) recibe una señal de colgar*, que comúnmente se abrevia como "señal HUP", o simplemente SIGHUP.
Ahora, cuando un proceso recibe una señal, puede manejarla como quiera**. El valor predeterminado para la mayoría de las señales (incluido HUP) es salir inmediatamente. Sin embargo, el programa es libre de ignorar la señal, o incluso ejecutar algún tipo de función de manejo de señal.
Bash elige la última opción. Su controlador de señal HUP verifica si la opción "huponexit" es verdadera y, de ser así, envía SIGHUP a cada uno de sus procesos secundarios. Solo una vez que termina con eso, Bash sale.
Del mismo modo, cada proceso hijo es libre de hacer lo que quiera cuando recibe la señal:déjelo en el valor predeterminado (es decir, muera inmediatamente), ignórelo o ejecute un controlador de señal.
Nohup solo cambia la acción predeterminada para el proceso secundario a "ignorar". Sin embargo, una vez que el proceso secundario se está ejecutando, es libre de cambiar su propia respuesta a la señal.
Esta, creo, es la razón por la que algunos programas mueren a pesar de que los ejecutó con nohup:
- Nohup establece la acción predeterminada en "ignorar".
- El programa necesita hacer algún tipo de limpieza cuando sale, por lo que instala un controlador SIGHUP, por cierto sobrescribe el indicador "ignorar".
- Cuando llega SIGHUP, el controlador se ejecuta, limpia los archivos de datos del programa (o lo que sea necesario) y sale del programa.
- El usuario no sabe ni se preocupa por el controlador o la limpieza, y solo ve que el programa se cerró a pesar de no haberlo hecho.
Aquí es donde entra en juego el "repudio". Un proceso que ha sido repudiado por Bash nunca recibe la señal HUP, independientemente de la opción huponexit. Entonces, incluso si el programa configura su propio controlador de señales, la señal nunca se envía realmente, por lo que el controlador nunca se ejecuta. Tenga en cuenta, sin embargo, que si el programa intenta mostrar algún texto a un usuario que ha cerrado sesión, provocará un error de E/S, lo que podría hacer que el programa se cierre de todos modos.
* Y, sí, antes de que preguntes, la terminología de "colgar" es un remanente de los días del mainframe de acceso telefónico de UNIX.
** La mayoría de las señales, de todos modos. SIGKILL, por ejemplo, siempre hace que el programa finalice inmediatamente, punto.
Los puntos 1-4 son correctos. No sé nada sobre el punto 5. En cuanto a su punto final, una buena aplicación, pantalla , le permitirá dejar que todos los procesos se ejecuten hasta su fin natural, independientemente de cómo finalice su conexión. La pantalla está en los repositorios.
La descripción del hombre de la pantalla no es fácil de leer, pero, entre otras cosas, dice:
Cuando se llama a screen, crea una sola ventana con un shell (o el comando especificado) y luego se aparta de su camino para que pueda usar el programa como lo haría normalmente. Luego, en cualquier momento, puede crear ventanas nuevas (a pantalla completa) con otros programas en ellas (incluyendo más shells), eliminar ventanas existentes, ver una lista de ventanas, activar y desactivar el registro de salida, copiar y pegar texto entre todas las ventanas, ver el historial de desplazamiento hacia atrás, cambiar entre ventanas de la manera que desee, etc. Todas las ventanas ejecutan sus programas de forma completamente independiente entre sí.Los programas continúan ejecutándose cuando su ventana no está visible e incluso cuando toda la pantalla la sesión se separa del terminal del usuario . Cuando un programa termina, screen (por defecto) elimina la ventana que lo contenía. Si esta ventana estaba en primer plano, la visualización cambia a la ventana anterior; si no queda ninguno, sale de la pantalla.
He resaltado la parte más importante:puede desconectar la ventana con el comando Ctrl+a+d, y luego puede cancelar/cerrar la sesión, y la ventana ahora desconectada seguirá viva, con los programas dentro aún ejecutándose. Cuando se vuelve a conectar, por ejemplo iniciando una nueva sesión ssh, el comando screen -r reanudará la sesión de pantalla que se había desconectado anteriormente, con toda la salida a error estándar/salida claramente visible.