Cosa succede all'output di un processo che è stato rinnegato e ha perso il suo terminale?

Se chiudo il terminale virtuale, da cui è stato avviato un processo, l'output si sposta direttamente /dev/nullo può in qualche modo inquinare la memoria? Posso comunque prendere l'output per continuare a leggerlo in qualsiasi momento dopo?

[EDIT]: Quindi, il momento di rinnegare un processo è effettivamente una fine della mia potenza per controllarne l'output?

Ho anche notato che se rinnegavo un processo interrotto, inizialmente tutto sembra normale: non viene né terminato né mostrato nei lavori. Ma se esco (e non intendo chiudere il terminale, esco da su, per esempio), il processo è terminato. Tuttavia, un processo sconosciuto in esecuzione in background può rimanere in esecuzione.

Il fatto che un processo sia "rinnegato" ha solo un significato per la shell interattiva che ha creato questo processo. Significa che la shell non include (più) il processo nella sua tabella dei lavori e che SIGHUP non verrà inviato a questo processo quando la shell esce. Non è realmente correlato alle tue domande.

Informazioni su ciò che accade agli output inviati a un terminale virtuale eliminato: ho eseguito alcuni test da solo e ho notato che i /dev/pts/xdispositivi non sono accessibili e non verranno allocati di nuovo fino a quando tutti i descrittori di file che puntano a loro non saranno chiusi. Quindi, non riesco a vedere un motivo per cui le scritture su un terminale eliminato verrebbero memorizzate. Suppongo che questo non sia nemmeno definito da POSIX.

A proposito di afferrare l'output di un processo che scrive su un terminale, non penso che sia possibile, anche quando il terminale è ancora vivo¹. Tutto quello che puoi fare è afferrare l'ingresso diretto al terminale (ovvero i tasti premuti o i tasti simulati dalla parte principale di un pty). Se i processi leggessero su stdin ciò che è scritto sui loro terminali, ciò porterebbe a un loop self io per la maggior parte dei processi.

A proposito dell'ultima osservazione sulla conclusione del processo, non so davvero cosa stia accadendo, ma sospetterei comportamenti piuttosto strani con segnali (SIGTTOU, SIGTTIN, SIGHUP o altri) relativi allo stato di primo piano / sfondo dei gruppi di processi, quando la sessione il leader esce (ad esempio su, nel caso in cui hai menzionato).

Risposta alla modifica: No, rispetto all'output, non cambia nulla quando un processo viene rinnegato: è ancora collegato al suo terminale di controllo (a meno che non si sia già staccato come i demoni). Puoi vederlo usando ps. Tuttavia, non sarà più possibile utilizzare i comandi fg/ bg/ jobsforniti dalla shell per questo processo. Ciò significa che potrebbe essere difficile alimentarlo con l'input dal terminale (richiede di essere nel gruppo di processo in primo piano).

-
^{1. a meno che il processo non sia disposto o dirottato con alcuni strumenti di debug (vedere i commenti sopra).}

Solo per rispondere a questa domanda specifica:

Se chiudo il terminale virtuale, dove è stato avviato un processo, l'output passa direttamente a / dev / null o può in qualche modo inquinare la memoria?

Il terminale e i programmi ad esso collegati comunicano tramite un dispositivo tty leggendolo e scrivendolo come un file. In particolare, un terminale virtuale crea uno "pseudo-tty" ("pty" in breve) e quindi genera un processo shell (o altro) e collega lo stdin / out / err di quel processo al pty. (I dettagli variano in base al sistema operativo.)

Quando si chiude il terminale virtuale, il terminale virtuale chiude la sua estremità della connessione (il pty "master"). Successivamente, se il programma all'altra estremità della connessione scrive su tty, viene restituito un errore e i dati non vanno da nessuna parte. Allo stesso modo, se legge dal tty, verrà restituito un indicatore EOF (fine del file).

Per rispondere alla parte più interessante della tua domanda: per modificare l'output di un programma in esecuzione dal vivo, devi modificarne i descrittori di file. Questo è abbastanza facile da fare con gdb. È un trucco, ma funziona.

Vedere:

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

Uno script di supporto è disponibile all'indirizzo http://users.linpro.no/ingvar/fdswap.sh.txt .

Grazie al commento di Gilles, che mi indica questa domanda , ho appreso un programma chiamato Retty .

Sembra usare un po 'di hack sporco per ricollegarsi a una (pseudo-) tanta possibilità di continuare a leggere l'output di un processo, indipendentemente dal fatto che sia stato rinnegato o meno. Quindi questo sembra rispondere alla maggior parte della prima parte della mia domanda. Il secondo è stato risposto da Stéphane .