.png)
Hoy observé algo que probablemente tenga una explicación fácil, pero que fue bastante inesperado por mi parte: estoy ejecutando CentOS (y RHEL, que se comporta igual). Abro un bash en una terminal e inicio cualquier subproceso como gedit. La ventana se abre, bien. Cuando hago un 'ps', puedo ver que gedit tiene bash como proceso principal, que a su vez tiene gnome-terminal como padre. Cuando detenga bash, esperaría que todos los procesos secundarios también se detuvieran. ¡Pero gedit sigue ejecutándose y el padre cambió a 1 (init)!
Intenté no detener el caparazón con gracia, sino matarlo con fuerza, y obtuve el mismo resultado. Intentó matar la terminal en lugar del shell, pero sigue siendo el mismo resultado. Solo cuando cierro la terminal haciendo clic en el botón X, gedit también se cierra.
No esperaba ese comportamiento. Comenzar gedit con nohup, no me sorprendería, pero incluso sin nohup... ¿por qué sigue vivo?
Quizás alguien pueda arrojar algo de luz y sepa qué está pasando allí. ¡Gracias de antemano!
Respuesta1
Programas como gedit, gvim, google-chrome y muchos otros pasan automáticamente a segundo plano. Esto le permite escribir
gedit /home/msw/ul-answer
asigne la nueva ventana y recupere el indicador de shell. No es una mala elección de diseño y, por lo general, existe una opción para anularla. Los comandos gedit -wy gvim --noforkno se separarán del terminal de control y no le devolverán el indicador de shell.
Para que un programa se ponga en segundo plano, se bifurca y luego el padre sale. Esto hará que su instancia normal de gedit sea hija de init (PPID == 1) casi inmediatamente después de escribirla.
Otros programas como mplayer o calibre no se ponen en segundo plano automáticamente porque no se escriben con frecuencia o porque les gusta volcar información de depuración en su terminal de control.
rareza añadida:
Después de pasar un poco de tiempo probando esto y observando la salida de strace y demás, parece que gedit no se pone en segundo plano automáticamente. Lo que dije sobre gvim todavía es válido y ya es hora de dormir, así que dejaré esto así por ahora.
Respuesta2
Cuando cierras la ventana de la terminal, el kernel envía unSuspiroseñal para golpear. Luego, Bash envía un SIGHUP a cada trabajo, por lo que mata a gedit con un SIGHUP.
Cuando sale de bash escribiendo exito Ctrl+ Do eliminándolo con SIGKILL, el emulador de terminal nota que su proceso hijo ha salido y cierra la ventana. Gedit no se ve afectado.