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).
It's a little hard to diagnose, as you don't give source for myproc
, but I suspect that your problem has something to do with "controlling TTY". I wrote a small shell script that just calls sleep 100
. I ran it under nohup
:
$ nohup ./sleeper > sleeper.out &
[1] 25305
-bash-3.2$ jobs
[1]+ Running nohup ./sleeper > sleeper.out &
-bash-3.2$ ps -l -p 25305
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 429624 25305 18252 0 77 0 - 15961 wait pts/0 00:00:00 sleeper
If you look at the ps
output, you see a column named "TTY". At least some versions of nohup
(the one I used above is from GNU coreutils, version 5.97, so relatively old). When I exited the bash shell from which I started sleeper
, the TTY column changed to '?', meaning that sleeper
didn't have one.
If myproc
doesn't deliberately detach itself from it's controlling TTY, it's still possible to get things like a SIGPIPE signal if it tries to write to stdout. It seems to me other things are possible, but I can't recall or google anything up.
If you can find or compile "daemonize", you might want to try it. If myproc
is compiled, you could modify the source to call the daemon(3)
library function.
Best Answer
nohup
anddisown -h
are not exactly the same thing.With
disown
, a process is removed from the list of jobs in the current interactive shell. Runningjobs
after starting a background process and runningdisown
will not show that process as a job in the shell. A disowned job will not receive aHUP
from the shell when it exits (but see note at end).With
disown -h
, the job is not removed from the list of jobs, but the shell would not send aHUP
signal to it if it exited (but see note at end).The
nohup
utility ignores theHUP
signal and starts the given utility. The utility inherits the signal mask fromnohup
and will therefore also ignore theHUP
signal. When the shell terminates, the process remains as a child process ofnohup
(andnohup
is re-parented toinit
).The difference is that the process started with
nohup
ignoresHUP
regardless of who sends the signal. The disowned processes are just not sent aHUP
signal by the shell, but may still be sent the signal from e.g.kill -s HUP <pid>
and will not ignore this.Note that
HUP
is only sent to the jobs of a shell ifhuponexit
shell option is set, orHUP
signal.Relevant bits from the
bash
manual (my emphasis):Related: