Ecco lo scenario ipotetico: Sto eseguendo uno script di test su un determinato hardware collegato alla casella A, a cui ho accesso root. Questo script di test richiede un input utente minimo (capovolgi un interruttore ogni mezz'ora o giù di lì). Circa un'ora e mezza nel processo di test, mi rendo conto che questo script impiega molto, molto tempo per terminare, per un totale di otto ore. La casella A si trova in una stanza server molto fredda e rumorosa, che in genere non è così divertente da occupare fisicamente. La scatola B si trova nel mio ufficio, dove ho una bella sedia comoda e una scorta infinita di tasche calde. Voglio in qualche modo monitorare l'output del processo in esecuzione sul box A da una sessione ssh nella casella B, quindi so quando andare a capovolgere l'interruttore, ma non voglio riavviare il processo di test. Se avessi saputo che il test avrebbe richiesto così tanto tempo per finire, avrei semplicemente trasmesso il suo output in un file di log e fatto un tail di quel file dalla mia sessione ssh della casella B. Se conosco il PID del processo in esecuzione sulla casella A, è possibile osservare lo stdout di quel processo da un'altra sessione?osservando lo stdout di un altro processo
Ovviamente, potrei semplicemente eseguire vnc sulla casella A e accedere dalla casella B per dare un'occhiata all'output, ma questo sconfigge lo scopo di questa ipotetica, che è di saperne di più su come process pipe, stdout, e l'output in generale funziona in un ambiente Linux.
Pensieri?
Questo è esattamente quello che speravo di trovare! Grazie - non avevo nemmeno preso in considerazione l'utilizzo di gdb per dirottare il descrittore di file del processo. –