☰

Sin nohup en csh, el trabajo en segundo plano sigue ejecutándose después de que sale ssh

tag-icon • tag-icon linux ssh signals csh nohup
Sin nohup en csh, el trabajo en segundo plano sigue ejecutándose después de que sale ssh

Estoy tratando de comprender la necesidad de utilizar nohupcomandos en segundo plano en ssh. Mi shell es csh en CentOS.

  1. El siguiente comando en segundo plano continúa ejecutándose incluso después de que se cierra ssh. Esperaba que esto solo sucediera si nohupestaba anteponiendo el comando.

    ¿Cuál es el escenario donde nohupsería necesario?

     ssh host 'sleep 80 >& /dev/null &'

  2. También probé un shell interactivo y el PID del trabajo en segundo plano todavía existe en el host después de que sale ssh.

     ssh host sleep 80 >& /dev/null & exit

  3. También intenté finalizar la sesión interactiva con kill -HUP PIDen lugar de exit, y el PID del trabajo en segundo plano todavía existe en el host después de que sale ssh.

¿Algo que estoy haciendo mal?

Respuesta1

No, unfondoEl grupo de procesos (trabajo) NO se elimina de forma predeterminada cuando el líder de la sesión (el shell) sale o cuando se desactiva su terminal de control.

Sólo hay algunos casos especiales en los que esto sucede:

(1)El trabajo de fondo esinterrumpido, en cuyo caso se enviará un SIGHUP/ SIGCONTpar de señales por parte delnúcleo. Si SIGHUPun proceso no capta o ignora la señal, el proceso terminará.

La definición de trabajo detenido es: cualquier trabajo que contenga un proceso detenido. Un procesodurmiendoen una llamada al sistema de bloqueo como nanosleep(2)o read(2)NO se considera detenida.

(2)Un proceso intenta leer o escribir en el terminal que ya no existe y sale (por su propia voluntad) debido a los errores que obtiene al intentar hacerlo.

(3)El trabajo es en realidad unprimer planotrabajo. Elnúcleoenvía una SIGHUPseñal al grupo de procesos de primer plano cuando finaliza el proceso líder/controlador de sesión (es decir, el shell). El propio proceso de control se señaliza SIGHUPcuando se desmonta su terminal de control, lo que normalmente provoca su terminación.

Incluso los comandos que comienzan con &son en realidad parte delprimer planogrupo de procesos cuando se inician desde un shell sin control de trabajo (que en la mayoría de los shells, pero no en csh, es el valor predeterminado cuando se ejecutaguionesysubcapas).

(4)Estás usando un shell como bashor zsh, que hace todo lo posible para enviar una SIGHUPseñal a todos sus trabajos cuando él mismo recibe la señal SIGHUP(según el punto 3 anterior, siendo el shell el proceso de control), o simplemente cuando sale (el este último solo es el predeterminado en zsh, pero no el predeterminado y sujeto a la shopt huponexitopción en bash).

Elcáscara csh(ya sea el real csho tcsh)no tiene ese comportamientodesde basho zsh. En tcsh(pero NO en el real csh) puede iniciar un comando con el hupcomando incorporado para que se active cuando se cierre el shell:

tcsh% hup sleep 3600 &
tcsh% exit
$ pgrep sleep
[nothing]

(5)Su sistema de inicio hace todo lo posible para limpiar cualquier sesión de usuario finalizada. En su configuración predeterminada,sistemadSeñalará todos los procesos desde unalcanceseguido SIGTERMde SIGKILLun retraso, por lo que nohupNO te ayudará con eso de todos modos. Además, la idea de systemd de unalcanceno coincide con una sesión de proceso Unix, por lo que ejecutar un comando setsid(1)tampoco permitirá que escape.

Probablemente puedas cambiar el comportamiento de systemd modificando las opciones predeterminadas KillUserProcesses=yes, KillMode=control-groupy .KillSignal=SIGTERMSendSIGKILL=yes

información relacionada