¿`Disown -h` y` nohup` funcionan efectivamente igual?

disown

• hace que un shell no envíe SIGHUP a su trabajo rechazado cuando finaliza el shell, y

• elimina el trabajo rechazado del control de trabajo del shell.

¿Es el primero el resultado del segundo? En otras palabras, si un proceso iniciado desde un shell se elimina del control de trabajo del shell de alguna manera, ¿el shell no enviará SIGHUP al proceso cuando finalice el shell?

disown -h todavía mantiene un proceso bajo el control de trabajo de un shell. ¿Significa que disown -hun proceso todavía recibe SIGHUP enviado desde el shell, pero establece la acción de SIGHUP por el proceso como "ignorar"? Eso suena similar a nohup.

$ sleep 123 & disown -h
[1] 26103
$ jobs
[1]+  Running                 sleep 123 &
$ fg 1
sleep 123
$ ^Z
[1]+  Stopped                 sleep 125
$ bg 1
[1]+ sleep 123 &
$ exit

$ ps aux | grep sleep
t        26103  0.0  0.0  14584   824 ?        S    15:19   0:00 sleep 123

¿ Hacemos disown -hy nohuptrabajamos efectivamente de la misma manera si ignoramos su diferencia al usar un terminal?

Gracias.

nohupy disown -hno son exactamente lo mismo.

Con disown, se elimina un proceso de la lista de trabajos en el shell interactivo actual. La ejecución jobsdespués de iniciar un proceso en segundo plano y la ejecución disownno mostrarán ese proceso como un trabajo en el shell. Un trabajo rechazado no recibirá un HUPmensaje del shell cuando salga (pero vea la nota al final).

Con disown -h, el trabajo no se elimina de la lista de trabajos, pero el shell no le enviará una HUPseñal si sale (pero vea la nota al final).

La nohuputilidad ignora la HUPseñal e inicia la utilidad dada. La utilidad hereda la máscara de señal nohupy, por lo tanto, también ignorará la HUPseñal. Cuando el shell termina, el proceso permanece como un proceso hijo de nohup(y nohupse vuelve a criar en init).

La diferencia es que el proceso comenzó con nohupignora HUPindependientemente de quién envía la señal. Los procesos rechazados simplemente no envían una HUPseñal por el shell , pero aún pueden enviar la señal, por ejemplo, kill -s HUP <pid>y no ignorarán esto.

Tenga en cuenta que HUPsolo se envía a los trabajos de un shell si

• el shell es un shell de inicio de sesión y se establece la huponexitopción de shell, o
• el propio shell recibe una HUPseñal.

Pedazos relevantes del bashmanual (mi énfasis):

SEÑALES

[...]

El shell sale por defecto al recibir aSIGHUP . Antes de salir, un shell interactivo reenvía SIGHUPa todos los trabajos, en ejecución o detenidos. Los trabajos detenidos se envían SIGCONTpara 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 disownbuiltin incorporado (ver más SHELL BUILTIN COMMANDSabajo) o marcarse para no recibir el SIGHUP uso disown -h.

Si la huponexitopción de shell se ha configurado con shopt, bashenvía un SIGHUPa todos los trabajos cuando sale un shell de inicio de sesión interactivo.

disown [-ar] [-h] [jobspec ... | pid ... ]

Sin opciones, elimine cada uno jobspecde la tabla de trabajos activos. [...] Si -hse da la opción, cada jobspecuna no se elimina de la tabla, sino que se marca para que SIGHUPno se envíe al trabajo si el shell recibe unSIGHUP . [...]

Relacionado:

• Diferencia entre nohup, disown y &

Ellos son diferentes:

• disown elimina el trabajo de la tabla de trabajos activos. Luego continúa con el trabajo actual. Con -h el proceso NO se envía SIGHUP. En cambio, se deja morir con el caparazón que lo contiene, cuando recibe un VISTAZO.

• nohup ignora el HUP. Luego, todo lo que hubiera pasado al terminal por el cierre del proceso en su lugar va a un archivo nohup.out.

  POSIX define nohup mientras que no lo es.