2

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.

Original Question

I filed an issue on tmux's GitHub issues tracker:

I've observed the following behavior in tmux: if I launch a background process from within a shell startup script (e.g., .bashrc or .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 .bashrc in a bare terminal, it also persists after the shell exits.

  • tmux v2.6
  • macOS 10.11 El Capitan
  • bash v4.4.12(1)

Official Response

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.

New Question

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 .bashrc / .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?

Ryan Lue
  • 1,076
  • Maybe something to do with .bashrc being sourced thus executing in the top level shell rather than being run like a script where it would execute in a subshell...? – B Layer Jan 22 '18 at 07:59

1 Answers1

1

The explanation given by M. Marriott is that tmux is not the cause of this.

The explanation for what you are seeing lies elsewhere, in particular with session leader programs, controlling terminals, the hangup signal, job control shells, the line discipline settings, and the daft high-jinks that systemd-logind (on systemd Linux operating systems) also introduces to the mix.

Further reading

JdeBP
  • 68,745