¿Qué sucede con los trabajos en segundo plano después de salir del shell?

A mi entender, los trabajos son tuberías iniciadas a partir de una cierta cáscara y se puede administrar estos puestos de trabajo ( fg, bg, Ctrl-Z) desde dentro de esta cáscara. Un trabajo puede consistir en múltiples procesos / comandos.

Mi pregunta es ¿qué sucede con estos trabajos cuando sale el shell original que contiene el shell? Suponga que huponexit no está configurado, de modo que los procesos en segundo plano continúan ejecutándose después de que el shell sale.

Supongamos que he hecho:

$ run.sh | grep 'abc' &
[1] job_id

Entonces salgo de este caparazón. Entraré en un nuevo shell y correré jobsy no veré nada obviamente. Pero puedo hacer ps aux | grep run.shy ver este proceso en ejecución y también lo haré ps aux | grep grepy veré el proceso para grep 'abc'ejecutar también.

¿Hay alguna manera de obtener la ID del trabajo para la tubería completa para que pueda matarlo de una vez, o tengo que matar todos los procesos por separado de otro shell una vez que salga del shell original? (He probado este último y funciona, pero parece una molestia hacer un seguimiento de todos los procesos).

Cuando el shell sale, puede enviar la señal HUP a trabajos en segundo plano, y esto puede hacer que salgan. La señal SIGHUP solo se envía si el shell mismo recibe un SIGHUP, es decir, solo si el terminal desaparece (por ejemplo, porque el proceso del emulador de terminal muere) y no si sale del shell normalmente (con el exitincorporado o escribiendo Ctrl+ D). Consulte ¿ En qué casos SIGHUP no se envía a un trabajo cuando cierra la sesión? y ¿Hay alguna variante de UNIX en la que un proceso secundario muere con su padre? para más detalles. En bash, puede configurar la huponexitopción para enviar también SIGHUP a trabajos en segundo plano en una salida normal. En ksh, bash y zsh, llamandodisownen un trabajo lo elimina de la lista de trabajos para enviar SIGHUP. Un proceso que recibe SIGHUP puede ignorar o captar la señal, y luego no morirá. El uso nohupcuando ejecuta un programa lo hace inmune a SIGHUP.

Si el proceso no se cancela debido a un posible SIGHUP, entonces queda atrás. No queda nada para relacionarlo con los números de trabajo en el shell.

El proceso aún puede morir si intenta acceder al terminal pero el terminal ya no existe. Eso depende de cómo reacciona el programa a una terminal inexistente.

Si el trabajo contiene múltiples procesos (por ejemplo, una tubería), entonces todos estos procesos están en un grupo de procesos . Los grupos de procesos se inventaron precisamente para capturar la noción de un trabajo de shell que se compone de múltiples procesos relacionados. Puede ver los procesos agrupados por grupo de procesos al mostrar su ID de grupo de proceso (PGID, normalmente la ID de proceso del primer proceso en el grupo), por ejemplo, con ps lLinux o algo así como ps -o pid,pgid,tty,etime,commportátil.

Puede eliminar todos los procesos en un grupo pasando un argumento negativo a kill. Por ejemplo, si ha determinado que el PGID para la tubería que desea matar es 1234, puede matarlo con

kill -TERM -1234

En general, todavía se ejecutan, pero debes usar nohup, si olvidaste o cambiaste de opinión, usa disown.

mike@mike-laptop4:~$ sleep 500
^Z
[1]+  Stopped                 sleep 500
mike@mike-laptop4:~$ bg
[1]+ sleep 500 &
mike@mike-laptop4:~$ jobs
[1]+  Running                 sleep 500 &
mike@mike-laptop4:~$ disown %1
mike@mike-laptop4:~$ jobs
mike@mike-laptop4:~$