I'm having difficulty understanding an answer I received to a question I posed about tmux — specifically, re: what the pseudoterminal does with child processes when it exits.
I've observed the following behavior in tmux: if I launch a background process from within a shell startup script (e.g.,
.profile) like so
# ~/.bashrc if [ -n "$TMUX" ]; then sleep 100 & fi
then this process is killed as soon as tmux exits. That is, after launching tmux, 1) I can pull up the PID with
pgrep sleep; 2) I can still see it after detaching from the tmux session; but 3) it is no longer present if I exit the tmux session entirely.
On the other hand, if I launch
sleep 100 &manually from the command prompt (from within tmux), then it persists even after tmux exits. And if I invoke
sleep 100 &via
.bashrcin a bare terminal, it also persists after the shell exits.
- tmux v2.6
- macOS 10.11 El Capitan
- bash v4.4.12(1)
Nicholas Marriott responded:
tmux just closes the pty master, that is where its involvement ends, the rest is up to the processes themselves and the kernel. If you want background processes (that do not manage it themselves) to reliably stay around after their parent process exits you need to use nohup.
How does @nicm's answer explain the behavior I described in the original issue?
In other words, why would the pty treat child processes spawned by
.profile differently from those spawned manually on the command line? (Or, why would the former be killed when the pty master is closed, while the latter would not?) And how is closing the pty master different from simply exiting a terminal emulator?