When tmux exits (closes pty master), background processes from startup scripts die â why?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
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 invokesleep 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?
tmux background-process bashrc profile pty
add a comment |Â
up vote
0
down vote
favorite
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 invokesleep 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?
tmux background-process bashrc profile pty
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 at 7:59
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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 invokesleep 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?
tmux background-process bashrc profile pty
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 invokesleep 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?
tmux background-process bashrc profile pty
asked Jan 22 at 3:07
Ryan Lue
1997
1997
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 at 7:59
add a comment |Â
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 at 7:59
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 at 7:59
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 at 7:59
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
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
- https://unix.stackexchange.com/a/379264/5132
- https://unix.stackexchange.com/a/310775/5132
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
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
- https://unix.stackexchange.com/a/379264/5132
- https://unix.stackexchange.com/a/310775/5132
add a comment |Â
up vote
1
down vote
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
- https://unix.stackexchange.com/a/379264/5132
- https://unix.stackexchange.com/a/310775/5132
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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
- https://unix.stackexchange.com/a/379264/5132
- https://unix.stackexchange.com/a/310775/5132
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
- https://unix.stackexchange.com/a/379264/5132
- https://unix.stackexchange.com/a/310775/5132
answered Jan 23 at 10:27
JdeBP
28.6k459134
28.6k459134
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f418733%2fwhen-tmux-exits-closes-pty-master-background-processes-from-startup-scripts-d%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 at 7:59