The fact that a process is "disowned" has only a meaning for the interactive shell that created this process. It means that the shell doesn't include (anymore) the process in its jobs table, and that SIGHUP will not be sent to this process when the shell exits. It is not really related with your questions.
About what happens to the outputs that are sent to a deleted virtual terminal: I made some tests myself, and I noticed that /dev/pts/x
devices are not accessible, and won't be allocated again until all filedescriptors that point to them have been closed. So, I can't see a reason why writes to a deleted terminal would be stored. I guess this is not even defined by POSIX.
About grabbing the output of some process that writes to a terminal, I don't think it is possible, even when the terminal is still alive¹. All you can do is grabbing the direct input to the terminal (i.e. keystrokes, or simulated keystrokes by the master part of a pty). If processes would read on stdin what is written to their terminals, that would lead to a self io loop for most process.
About the last remark on process termination, I don't really know what is happening, but I would suspect rather strange behaviors with signals (SIGTTOU, SIGTTIN, SIGHUP, or others) related to foreground/background state of process groups, when the session leader exits (e.g. su
, in the case you mentioned).
Answer to the Edit: No, with respect to output, nothing changes when a process is disowned: it is still attached to its controlling terminal (unless it detached itself already like daemons do). You can see that using ps
. However, you will not be able to use fg
/bg
/jobs
commands provided by the shell anymore for this process. That means it might be difficult to feed it with input from the terminal (requires to be in the foreground process group).
—
1. unless the process is willing to, or hijacked with some debugging tools (see comments above).
retty
program. – rozcietrzewiacz Aug 02 '11 at 12:47