¿Qué sucede con la salida de un proceso que ha sido repudiado y perdió su terminal?

Si cierro la terminal virtual, donde se inició algún proceso, ¿la salida va directamente a /dev/null, o puede contaminar la memoria de alguna manera? ¿De todos modos, puedo tomar la salida para continuar leyendo en cualquier momento después de eso?

[EDITAR]: Entonces, ¿es el momento de rechazar un proceso efectivamente un fin de mi poder para controlar su salida?

También me di cuenta de que si rechazo un proceso detenido, al principio todo parece normal: no se termina ni se muestra en los trabajos. Pero si me desconecto (y no me refiero a cerrar la terminal, simplemente salir de su, por ejemplo), el proceso finaliza. De todos modos, un proceso desautorizado en segundo plano puede seguir ejecutándose.

El hecho de que un proceso sea "repudiado" solo tiene un significado para el shell interactivo que creó este proceso. Significa que el shell ya no incluye (más) el proceso en su tabla de trabajos, y que SIGHUP no se enviará a este proceso cuando el shell salga. Realmente no está relacionado con sus preguntas.

Acerca de lo que sucede con las salidas que se envían a un terminal virtual eliminado: /dev/pts/xRealicé algunas pruebas por mí mismo, y noté que los dispositivos no son accesibles, y no se asignarán nuevamente hasta que se hayan cerrado todos los descriptores de archivos que apuntan a ellos. Entonces, no puedo ver una razón por la cual las escrituras en un terminal eliminado se almacenarían. Supongo que esto ni siquiera está definido por POSIX.

Acerca de tomar la salida de algún proceso que escribe en una terminal, no creo que sea posible, incluso cuando la terminal todavía está viva¹. Todo lo que puede hacer es tomar la entrada directa al terminal (es decir, pulsaciones de teclas o pulsaciones de teclas simuladas por la parte maestra de una pty). Si los procesos leyeran en stdin lo que está escrito en sus terminales, eso conduciría a un bucle de auto io para la mayoría de los procesos.

Sobre el último comentario sobre la finalización del proceso, realmente no sé lo que está sucediendo, pero sospecharía comportamientos bastante extraños con señales (SIGTTOU, SIGTTIN, SIGHUP u otras) relacionadas con el estado de primer plano / fondo de los grupos de procesos, cuando la sesión salidas de líder (por ejemplo su, en el caso que mencionó).

Respuesta a la edición: No, con respecto a la salida, nada cambia cuando se desautoriza un proceso: todavía está conectado a su terminal de control (a menos que ya se haya desconectado como lo hacen los demonios). Puedes ver eso usando ps. Sin embargo, ya no podrá usar los comandos fg/ bg/ jobsproporcionados por el shell para este proceso. Eso significa que puede ser difícil alimentarlo con la entrada del terminal (requiere estar en el grupo de procesos en primer plano).

-
^{1. a menos que el proceso esté dispuesto o sea secuestrado con algunas herramientas de depuración (ver comentarios más arriba).}

Solo para abordar esta pregunta específica:

Si cierro la terminal virtual, donde se inició algún proceso, ¿la salida va directamente a / dev / null, o puede contaminar la memoria de alguna manera?

El terminal y los programas conectados se comunican a través de un dispositivo tty leyéndolo y escribiéndolo como un archivo. Específicamente, un terminal virtual crea un "pseudo-tty" ("pty" para abreviar) y luego genera un proceso de shell (u otro) y conecta el stdin / out / err de ese proceso al pty. (Los detalles varían según el sistema operativo).

Cuando cierra el terminal virtual, el terminal virtual cierra su final de la conexión (el "maestro" pty). Después de eso, si el programa en el otro extremo de la conexión escribe en el tty, se devuelve un error y los datos no van a ninguna parte. De manera similar, si lee desde el tty, obtendrá un indicador EOF (fin de archivo).

Para responder la parte más interesante de su pregunta: para cambiar la salida de un programa en vivo, debe editar sus descriptores de archivo. Eso es bastante fácil de hacer con gdb. Es un truco, pero funciona.

Ver:

/programming/593724/redirect-stderr-stdout-of-a-process-after-its-been-started-using-command-line

Un script auxiliar está disponible en http://users.linpro.no/ingvar/fdswap.sh.txt .

Gracias al comentario de Gilles, al señalarme esta pregunta , aprendí sobre un programa llamado retty .

Parece utilizar algún truco sucio para volver a conectarlo a una (pseudo-) tty que permita continuar leyendo el resultado de un proceso, sin importar si se ha desautorizado o no. Así que esto parece responder la mayor parte de la primera parte de mi pregunta. El segundo fue respondido por Stéphane .