When tmux exits (closes pty master), background processes from startup scripts die — why?

The name of the pictureThe name of the pictureThe name of the pictureClash 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 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?







share|improve this question




















  • 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















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 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?







share|improve this question




















  • 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













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 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?







share|improve this question












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?









share|improve this question











share|improve this question




share|improve this question










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

















  • 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











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





share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    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






























    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





    share|improve this answer
























      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





      share|improve this answer






















        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





        share|improve this answer












        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






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 23 at 10:27









        JdeBP

        28.6k459134




        28.6k459134






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay