¿Cuándo necesita 'nohup' si ya está bifurcando con '&'?

Primero, esta pregunta está relacionada, pero definitivamente no es lo mismo que esta muy buena pregunta:

Quiero entender algo: cuando hago '&', me estoy bifurcando, ¿verdad?

¿Alguna vez es útil hacer "nohup ... &" o es simple y suficiente?

¿Alguien podría mostrar un caso en el que estaría usando '&' y todavía querría usar 'nohup'?

shell nohup fork

— Cedric Martin
fuente

¿Has leído la respuesta aceptada y su hilo de comentarios? Ellos explican lo que nohuphace. ¿Qué parte has confundido?

— Gilles 'SO- deja de ser malvado'

@Gilles: puede ser obvio para usted , porque está familiarizado con estas cosas (visto su representante) ... Sin embargo, para empezar, la respuesta aceptada en el enlace que puse no dice una palabra sobre el uso tanto nohup como '&' ... estoy bastante seguro de que mi pregunta es lo suficientemente clara y diferente de la otra, y dos excelentes respuestas aquí parecen demostrarlo; ) Además, ¿estás realmente insinuando que me tomé la molestia de vincularme a otra pregunta, pero sin leer la respuesta aceptada?

— Cedric Martin

Respuestas:

En primer lugar, cada vez que ejecutas un comando, tu shell bifurcará un nuevo proceso, independientemente de si lo ejecutas &o no. &solo significa que lo estás ejecutando en segundo plano.

_{Tenga en cuenta que esto no es muy preciso. Algunos comandos, como cdson funciones de shell, no suelen bifurcar un nuevo proceso. type cmdgeneralmente le dirá si cmdes un comando externo o una función de shell. type typete dice que typesí es una función de shell.}

nohupEs algo diferente. Le dice al nuevo proceso que ignore SIGHUP. Es la señal enviada por el núcleo cuando se cierra el shell principal.

Para responder a su pregunta, haga lo siguiente:

ejecutar emacs & (por defecto debe ejecutarse en una ventana X separada) .
en el shell principal, ejecute exit.

Notarás que la emacsventana se cierra, a pesar de ejecutarse en segundo plano. Este es el comportamiento predeterminado y nohupse usa precisamente para modificarlo.

Ejecutar un trabajo en segundo plano (con &o bg, apuesto a que otros shells también tienen otras sintaxis) es una característica de shell, derivada de la capacidad de los sistemas modernos para realizar múltiples tareas. En lugar de bifurcar una nueva instancia de shell para cada programa que desea iniciar, conchas modernas ( bash, zsh, ksh, ...) tendrá la posibilidad de gestionar una lista de programas (o trabajos ). Solo uno de ellos a la vez puede estar en primer plano , lo que significa que obtiene el foco de shell. Desearía que alguien pudiera ampliar más las diferencias entre un proceso que se ejecuta en primer plano y uno en segundo plano (el principal es el acceso a stdin/ stdout).

En cualquier caso, esto no afecta la forma en que reacciona el proceso secundario SIGHUP. nohuphace.

— rahmu
fuente

Haga un +1 a ambos por las excelentes respuestas ... Pero todavía estoy confundido ... Intenté eso antes de responder a mi pregunta: tal vez mi (muy antigua) configuración de Debian Linux no está configurada correctamente, pero si "emacs & "y luego escriba" exit ", solo mi xterm sale: emacs permanece allí.

— Cedric Martin

Emacs es lo suficientemente complicado como para que pueda manejar SIGHUP por sí solo. Solo de forma predeterminada los procesos salen en SIGHUP. Muchos programas 'daemon' como ntpd o inetd volverán a leer su configuración en SIGHUP en lugar de salir. Soy un chico vim, así que no tengo mucha experiencia con ningún emacs.

— Bruce Ediger

No hay nada especial en emacs. Un shell normalmente envía SIGHUPa sus procesos hijos cuando el shell recibe SIGHUP, no cuando el shell sale normalmente. bash tiene una opción huponexitque hace que se envíe SIGHUPa los niños cuando sale, pero no está habilitada de manera predeterminada. gnu.org/software/bash/manual/bashref.html#Signals

— Keith Thompson

Hola. En primer lugar, una gran explicación. Traté de verificar su tesis ejecutando un proceso con &y cerré mi shell ejecutando exit. El proceso aún se está ejecutando. ¿Alguna idea de por qué no ha sido asesinado? ¿O me estoy perdiendo algo aquí?

— Ali Yılmaz

¿Cuál es el proceso que estás ejecutando?

— rahmu

¿Alguna vez es útil hacer nohup ... &? Sí. Si solo comienza un proceso "en segundo plano" con &, ese nuevo proceso todavía tiene membresía en el "grupo de procesos" del shell original. Si ese shell o el grupo de proceso recibe ciertas señales (SIGHUP, por ejemplo), por defecto salen. Esto significa que si ejecuta un proceso &desde un shell iniciado por un xterm, o rxvt o algún otro emulador de terminal de ventanas, cuando cierra la ventana, el proceso en segundo plano obtiene un SIGHUP. La mayoría de los códigos escritos casualmente no manejan SIGHUP y, por lo tanto, salen.

Si lo hace nohup ... &, el nohupcomando configura SIGHUP como ignorado y luego ejecuta el comando. Ese comando recién ejecutado mantiene la máscara de señal que se nohupconfiguró, a menos que el comando maneje algunas señales por sí mismo. Si cierra xterm o rxvt o lo que sea, el núcleo entrega SIGHUP al proceso del comando, que se ignora. Se sigue corriendo.

Hacer un nohupcomando le permite seguir ejecutándose después de cerrar xterm o cerrar sesión.

— Bruce Ediger
fuente

Lo siento, me perdiste. ¿Está diciendo que usar &with nohupmantiene el comando ejecutándose en ciertos casos en los que solo usar nohupno lo haría? Eso parece estar en conflicto con la respuesta aquí: unix.stackexchange.com/a/288064/1822

— Mike B

@MikeB: el "&" realiza las llamadas habituales del sistema fork / set things / exec para poner el comando "en segundo plano". Es decir, el comando que no se activa se ejecuta de forma asincrónica. La nohuphace algunas cosas antes de la exec()llamada al sistema para que el proceso de horquilla ignorar ciertas señales. Entonces, sí, un "&" permitirá que se ejecute un comando bajo ciertas circunstancias que un viejo nohupno lo haría. Como cerrar el xterm asociado con el shell que hizo el nohup, o cerrar sesión.

— Bruce Ediger

-1

si ejecuta un programa en segundo plano (con & como sufijo) en el sistema operativo Linux y cierra sesión incluso después de eso, seguirá ejecutándose: pruebe con:

  ping google.com > ping_result  &

Después de volver a iniciar sesión, verifique el número de líneas en el archivo de salida ping_resultque seguirá aumentando significa que todavía se está ejecutando, sin embargo, se le ha dicho que se cerrará. entonces, ¿para qué sirve el nohupcomando?

otro escenario ==> como se indicó anteriormente para nohup emac &-> que debería seguir emacejecutándose después del cierre de sesión del sistema pero no muestra la ejecución después de volver a iniciar sesión.

— aditya
fuente