Si inicio un proceso en segundo plano y luego cierre sesión, ¿continuará ejecutándose?

Al preguntar esto después de una discusión prolongada con un compañero de trabajo, realmente me gustaría una aclaración aquí.

Lanzo un proceso en segundo plano, ya sea agregando " &" a la línea de comando o deteniéndolo CTRL-Zy reanudándolo en segundo plano con " bg". Luego me desconecto.

¿Lo que pasa?

Estábamos bastante seguros de que debería haber sido asesinado por un SIGHUP, pero esto no sucedió; Al iniciar sesión nuevamente, el proceso se ejecutó felizmente y pstreemostró que fue "adoptado" por init.

Es este el comportamiento esperado?

Pero entonces, si es así, ¿cuál es el nohuppropósito del comando? Simplemente parece que el proceso no se va a matar de todos modos, con o sin él ...

Editar 1

Algunos detalles más:

• El comando se inició desde una sesión SSH, no desde la consola física.
• El comando se lanzó sin nohup y / o &; luego se suspendió con CTRL-Zy se reanudó en segundo plano con bg.
• La sesión ssh no cayó. Hubo un cierre de sesión real (" exit" comando).
• El proceso fue una scpoperación de copia de archivos.
• Al iniciar sesión nuevamente, pstreemostró el proceso ejecutándose y siendo hijo de init.

Editar 2

Para plantear la pregunta más claramente: ¿poner un proceso en segundo plano (usando &o bg) hará que se ignore SIGHUP, tal como lo hace el nohupcomando?

Editar 3

Traté de enviar manualmente un SIGHUPa scp: salió, por lo que definitivamente no ignora la señal.

Luego intenté nuevamente iniciarlo, ponerlo en segundo plano y cerrar sesión: fue "adoptado" inity siguió ejecutándose, y lo encontré allí cuando volví a iniciar sesión.

Estoy bastante perplejo ahora. Parece que no SIGHUPse envió ningún mensaje a lo largo del cierre de sesión.

Respuesta encontrada.

Para BASH, esto depende de la huponexitopción de shell, que se puede ver y / o configurar con el shoptcomando incorporado .

Parece que esta opción está desactivada de forma predeterminada, al menos en los sistemas basados ​​en RedHat.

Más información en la página de manual de BASH :

El shell sale por defecto al recibir un SIGHUP. Antes de salir, un shell interactivo reenvía el SIGHUP a todos los trabajos, en ejecución o detenidos. Los trabajos detenidos se envían SIGCONT para garantizar que reciban el SIGHUP. Para evitar que el shell envíe la señal a un trabajo en particular, debe eliminarse de la tabla de trabajos con el mensaje desplegado incorporado (consulte COMANDOS DE CONSTRUIR SHELL a continuación) o marcado para no recibir SIGHUP usando disown -h.

Si la opción de shell huponexit se ha configurado con shopt, bash envía un SIGHUP a todos los trabajos cuando sale un shell de inicio de sesión interactivo.

Estoy de acuerdo con Warner y solo quiero agregar que puedes evitar que el shell envíe SIGHUP con el comando "disown" incorporado. La página de manual de bash contiene una buena descripción.

Puede usar el comando nohup para iniciar el comando y redirigir la salida a un archivo de salida nohup. Desde la página de manual de nohup:

nohup - run a command immune to hangups, with output to a non-tty

La otra opción es usar el comando de pantalla . El beneficio de usar la pantalla es que puede volver a conectarse al proceso más adelante.

Cuando se bifurca un proceso en segundo plano, seguirá siendo el proceso secundario del shell que lo ejecuta.

Todos los procesos secundarios que se ejecutan bajo un shell reciben un SIGHUP al salir. El rendimiento varía ligeramente según la situación exacta, que se detalla detalladamente en la página de manual de bash. Otros proyectiles probablemente tienen descripciones similares.

Apache y otros demonios, normalmente recargan la configuración en SIGHUP. Las utilidades del espacio de usuario a menudo mueren. El rendimiento de la aplicación vinculado a las señales puede ser exclusivo de la aplicación.

¿Cuál fue el proceso? El rendimiento descrito en la publicación anterior 1 fue exacto.

Ciertas funciones y procesos de script pueden atrapar señales. mientras que los bucles pueden escapar como locos.

Ver:

La sesión SSH cae - ¿El comando continúa ejecutándose?

Edición 1 a las 4:22 PM

Desde la página de manual de bash:

The shell exits by default upon receipt of a SIGHUP.   Before  exiting,
an  interactive  shell  resends  the  SIGHUP  to  all  jobs, running or
topped.

La investigación inicial 1 muestra que OpenSSH probablemente ignora SIGHUP, tal vez más señales.

Si no ejecutó el comando a través de una herramienta como screen, entonces, cuando finaliza la sesión, haga todos los trabajos / tareas asociados con esa sesión.