Aquí está el escenario hipotético: Estoy ejecutando un script de prueba en algún hardware conectado al cuadro A, al que tengo acceso de root. Este script de prueba requiere una mínima intervención del usuario (enciende un interruptor cada media hora más o menos). Aproximadamente una hora y media en el proceso de prueba, me doy cuenta de que este guión tarda mucho, mucho tiempo en terminar, en una melodía de ocho horas. El recuadro A está ubicado en una sala de servidores muy fría y ruidosa que generalmente no es tan divertida de ocupar físicamente. La caja B se encuentra en mi oficina, donde tengo una silla cómoda y un suministro interminable de bolsillos calientes. Quiero algún modo de supervisar el resultado del proceso que se ejecuta en el recuadro A de una sesión ssh en el recuadro B, de modo que sé cuándo ir a cambiar el interruptor, pero no quiero reiniciar el proceso de prueba. Si hubiera sabido comenzar con que la prueba tardaría tanto en terminar, simplemente habría canalizado su salida a un archivo de registro y colado ese archivo de mi sesión B ssh. Si conozco el PID del proceso que se ejecuta en el recuadro A, ¿es posible observar el estándar de ese proceso desde otra sesión?observando la salida estándar de otro proceso
Por supuesto, podría ejecutar vnc en la casilla A e ingresar desde la casilla B para ver la salida, pero eso frustra el propósito de esta hipotética, que es aprender más acerca de cómo las tuberías de proceso, stdout, y salida en trabajo general en un entorno Linux.
¿Pensamientos?
¡Esto es exactamente lo que esperaba encontrar! Gracias. Ni siquiera había considerado utilizar gdb para secuestrar el descriptor de archivo del proceso. –