yes, this is a known problem when a stale client is left behind, it used to happen because we did not pick up HUP, but we do now
micahcowan and i started discussing this as a potential problem with ssh before, because ssh will not know to disconnect the client (tcp will not tell it), so tmux will never know either, but we were both called away and didn't finish the conversation probably what is happening is that ssh or the pty buffers fill and it is no longer reading from the pty so it hits the backoff limit and reading from any windows shown on that client is suspended maybe we are doing backoff the wrong way. maybe a better way would be to suspend /writing/ to the client until the buffer drains, then flush the pending data and force a redraw. this might be harder to achieve though On Wed, Jul 21, 2010 at 09:54:53PM -0400, Samer Atiani wrote: > The problem has happened to me again, but I was able to fix it after it > occured. > I typed "C-b : lsc" *and it returned this: > /dev/pts/4: 0 [208x62 xterm] * * * * * * * * * * * * * * * * * * * * * * * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * * * * * * * * * * * * * * * * * * * * * * * * * * * [0/2] > /dev/pts/5: 0 [208x62 xterm] > so I detached and from the terminal I typed: > tmux detach -t /dev/pts/4 > so that the result of the statement "tmux list-clients" is nothing. Then I > attached again with tmux attach and all was fixed. > Now onto finding what was using /dev/pts/4: > $ ls -al | grep ssh > ... [output redacted] > 5 S satiani * 1943 *1874 *0 *80 * 0 - 19735 poll_s 15:03 ? * * * *00:00:00 > sshd: sati...@pts/4 > ...*[output redacted] > 5 S satiani *26350 26286 *0 *80 * 0 - 19735 poll_s 21:35 ? * * * *00:00:00 > sshd: sati...@pts/5 > ...*[output redacted] > So it looks like there is a stale ssh connection to the machine (process > 1943) that was never closed properly after my connection died. Since I was > still attached to tmux at the time my connection died I think thats what > caused it. Indeed, I was able to reproduce the problem: > Reproduction steps: > On Windows XP: > 1- Open a VPN connection to the network hosting the target machine. > 2- PuTTY to the machine, open a new tmux session. > 3- Without closing PuTTY or tmux, disconnect the VPN connection. > 4- Reopen the VPN and reconnect to the machine, check your ssh connection > processes and confirm that there is a stale connection from your > interrupted session. > 5- Attach tmux. At first it appears you can type a few keystrokes, but > eventually the windows will freeze. You should still be able to use tmux > keybindings to execute tmux commands but the windows themselves won't > respond to your keystrokes unless you switch to another window and then > back to the original window. > I can reliably reproduce this problem using the steps outlined above. You > can fix the problem either by issuing a tmux detach on the pts of the > stale connection or from outside tmux by killing the stale connection. > Samer > On Wed, Jul 21, 2010 at 3:59 PM, Richard Morse <[1]remo...@partners.org> > wrote: > > This is tmux running locally. > > Ricky > On Jul 21, 2010, at 3:58 PM, Nicholas Marriott wrote: > > > over ssh or running natively? > > > > sounds like problems with SIGWINCH or TIOCGWINSZ > > > > > > On Wed, Jul 21, 2010 at 03:55:35PM -0400, Richard Morse wrote: > >> Is it related to changing the terminal size (ie, the PuTTY window > size) too quickly? I've just discovered that quickly changing the size > of the Terminal.app window can sometimes cause tmux to stop updating the > screen until the window is sized back to the size it had been... > >> > >> Ricky > >> > >> On Jul 21, 2010, at 3:17 PM, Samer Atiani wrote: > >> > >>> Yes, its 1.4.14b , sorry. > >>> > >>> As I said I can't reproduce it, so I don't know exactly the sequence > of > >>> events that leads to this behavior, nor do I have this problem > happening to > >>> me now so I can answer your other questions. > >>> > >>> However, I'll keep you posted the next time it happens. > >>> > >>> Many thanks for your help, > >>> Samer > >>> > >>> On Wed, Jul 21, 2010 at 3:13 PM, Nicholas Marriott < > >>> [2]nicholas.marri...@gmail.com> wrote: > >>> > >>>> I take it that is 1.4.14b libevent. > >>>> > >>>> So are you doing anything particular when it happens? Running any > >>>> particular program? > >>>> > >>>> After it freezes, can you still detach tmux? What does "C-b : lsc" > say > >>>> after it happens? Does C-b r fix it? > >>>> > >>>> > >>>> On Wed, Jul 21, 2010 at 03:10:49PM -0400, Samer Atiani wrote: > >>>>> *libevent version: 1.4.1b-stable > >>>>> *tmux version: 1.2 > >>>>> *platform: ubuntu 9.10, debian squeeze > >>>>> *TERM inside tmux: screen > >>>>> *TERM outside tmux: xterm > >>>>> > >>>>> *On Wed, Jul 21, 2010 at 2:59 PM, Nicholas Marriott > >>>>> *<[1][3]nicholas.marri...@gmail.com> wrote: > >>>>> > >>>>> * *What tmux version, what platform is it running on, what is TERM > set > >>>> to > >>>>> * *inside and outside tmux, what version of libevent? > >>>>> > >>>>> * *On Wed, Jul 21, 2010 at 02:46:26PM -0400, Samer Atiani wrote: > >>>>>> * *Hello, > >>>>>> * *I'm having a weird problem were tmux windows stop reacting to > >>>> my > >>>>>> * *keystrokes interactively, this problem only happens to me in > >>>> PuTTY. > >>>>>> * *When the problem happens, tmux bindings still work (I can > >>>> switch > >>>>> * *between > >>>>>> * *windows, go into command/copy mode, etc.), however, when I > type > >>>>> * *something > >>>>>> * *into the window the terminal doesn't respond to my keystrokes. > >>>>> * *Whats > >>>>>> * *interesting is that if I switch to another window and then > back > >>>>> * *into the > >>>>>> * *original window, *whatever I originally typed before switching > >>>> will > >>>>> * *be > >>>>>> * *visible now. > >>>>>> * *I do not know how to reproduce this problem, so far it happens > >>>>>> * *sporadically (it has happened to me twice today so far). > >>>>>> * *Can you please help me with resolving this problem? > >>>>>> * *Samer > >>>>> > >>>>>> > >>>>> > >>>> > > ------------------------------------------------------------------------------ > >>>>>> This SF.net email is sponsored by Sprint > >>>>>> What will you do first with EVO, the first 4G phone? > >>>>>> Visit [2][4]sprint.com/first -- [3] > >>>> [5]http://p.sf.net/sfu/sprint-com-first > >>>>> > >>>>>> _______________________________________________ > >>>>>> tmux-users mailing list > >>>>>> [4][6]tmux-us...@lists.sourceforge.net > >>>>>> [5][7]https://lists.sourceforge.net/lists/listinfo/tmux-users > >>>>> > >>>>> References > >>>>> > >>>>> *Visible links > >>>>> *1. mailto:[8]nicholas.marri...@gmail.com > >>>>> *2. [9]http://sprint.com/first > >>>>> *3. [10]http://p.sf.net/sfu/sprint-com-first > >>>>> *4. mailto:[11]tmux-us...@lists.sourceforge.net > >>>>> *5. [12]https://lists.sourceforge.net/lists/listinfo/tmux-users > >>>> > >>> > > ------------------------------------------------------------------------------ > >>> This SF.net email is sponsored by Sprint > >>> What will you do first with EVO, the first 4G phone? > >>> Visit [13]sprint.com/first -- > > [14]http://p.sf.net/sfu/sprint-com-first_______________________________________________ > >>> tmux-users mailing list > >>> [15]tmux-us...@lists.sourceforge.net > >>> [16]https://lists.sourceforge.net/lists/listinfo/tmux-users > >> > >> > >> > >> The information in this e-mail is intended only for the person to > whom it is > >> addressed. If you believe this e-mail was sent to you in error and > the e-mail > >> contains patient information, please contact the Partners Compliance > HelpLine at > >> [17]http://www.partners.org/complianceline . If the e-mail was sent > to you in error > >> but does not contain patient information, please contact the sender > and properly > >> dispose of the e-mail. > >> > > References > > Visible links > 1. mailto:remo...@partners.org > 2. mailto:nicholas.marri...@gmail.com > 3. mailto:nicholas.marri...@gmail.com > 4. http://sprint.com/first > 5. http://p.sf.net/sfu/sprint-com-first > 6. mailto:tmux-users@lists.sourceforge.net > 7. https://lists.sourceforge.net/lists/listinfo/tmux-users > 8. mailto:nicholas.marri...@gmail.com > 9. http://sprint.com/first > 10. http://p.sf.net/sfu/sprint-com-first > 11. mailto:tmux-users@lists.sourceforge.net > 12. https://lists.sourceforge.net/lists/listinfo/tmux-users > 13. http://sprint.com/first > 14. > http://p.sf.net/sfu/sprint-com-first_______________________________________________ > 15. mailto:tmux-users@lists.sourceforge.net > 16. https://lists.sourceforge.net/lists/listinfo/tmux-users > 17. http://www.partners.org/complianceline ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
