Esta es más una pregunta de gestión de procesos/manejo de señales que una pregunta de Bash. Simplemente usa Bash para explicar el problema.
Estoy ejecutando un script Bash en el que ejecuto un proceso en segundo plano. Este es el guión:
#!/bin/bash
# ...
# The background process
{
while :; do
sleep 1 && echo foo >> /path/to/some/file.txt
done
} &
# ...
exit 0
NO ejecuto el script en segundo plano. Simplemente ./script.
La opción de shell "huponexit" se habilita usando shopt -s huponexit, por lo tanto, cuando se cierra la terminal, espero que envíe una señal HUP a Bash, que la propagará hasta que llegue al proceso en segundo plano. Si el proceso en segundo plano no trapignora la señal, también se eliminará, pero esto no sucede. El proceso en segundo plano actúa como si estuviera disowneditado.
Este es un esquema que dibujo para ilustrar el tema. El esquema, junto con la descripción anterior, puede estar equivocado ya que estoy seguro de que no entiendo el tema lo suficientemente bien. Por favor, arréglenme eso si realmente es el caso.
Quiero saber por qué el proceso en segundo plano no se elimina después de cerrar la terminal, como si fuera invocado por un shell interactivo como ese:
rany@~/Desktop$ while :; do sleep 1 && echo foo >> /path/to/some/file.txt; done &
No estoy seguro, pero supongo que la respuesta a mi pregunta radica en el hecho de que Bash fork() es un shell no interactivo para ejecutar el script que podría tener un conjunto diferente de reglas para el control de trabajos y el manejo de señales.
Respuesta1
Entonces, ¿qué nos dice la página de manual huponexit?
Si la opción de shell huponexit se ha configurado con shopt, bash envía un SIGHUP a todos los trabajos cuandoinicio de sesión interactivoel caparazón sale.
EDITAR: enfatizando que es un shell de INICIO DE SESIÓN.
EDITAR 2: lo interactivo merece el mismo énfasis