We've been using GNU screen on our jump box to have ssh sessions open to multiple hosts within our private network. One window per host.

Recently we've built a new environment and are experiencing frequent screen hangs. Most often when a lot of terminal output is being spooled to the screen (cat'ing a file for instance), screen becomes unresponsive. The terminal stops updating mid-command, and I can't switch to any other screen window.

I can log into the jump box again, and do a screen -dr , and it attaches like nothing was the matter. The .screenrc we use is:

bindkey -k k2 screen
bindkey -k k3 prev
bindkey -k k4 next
bindkey -k k7 copy
bindkey -k k8 title
bindkey -k k9 windows
startup_message off
hardstatus alwayslastline
hardstatus string "%-w%{= BW}%50>%n %t%{-}%+w%<"
nonblock on

While a screen session is frozen like this, can you suggest what I should be looking at to work out what the cause is because I'm fairly stumped?

This is under debian wheezy, screen=4.1.0~20120320gitdb59704-7, and these are EC2 instances in case that's relevant.

  • If you cat a file, the terminal may end up interpreting a sequence. You can try a couple of things: check if you can issue reset and also try to toggle XON/XOFF.
    – dawud
    Nov 14, 2014 at 9:47
  • OK will try that next time. If it happens because of a control sequence in a file, then it should always happen when cat'ing that file right? Should add it's not always cat'ing a file, sometimes just a command that generates a lot of output. Also, sometimes the sessions appears to recover after hanging for 20+ seconds.
    – David QC
    Nov 14, 2014 at 9:59
  • This could be an MTU problem in the underlying network. That is, there is a packet larger than the network MTU, and it gets dropped at some point in the network, therefore freezing the connection. Nov 14, 2014 at 10:45
  • bindkey? You're using zsh? What happens if you change shells (bash)?
    – Signal15
    Dec 12, 2014 at 16:23

1 Answer 1


On occasion, the xterm you're using gets a Ctrl-S from whatever output is being parsed. This causes the session to "lock" in place (like a "pause"), and you can hit Ctrl-Q to resume. There have been several instances where this happens.

History: Ctrl-S sends a "Software Flow Control Off (XOFF)" to the remote host, Ctrl-Q sends the XON.

SSH Tip: If the above doesn't work; Next time the SSH session hangs on you, type ~. (that's "Tilde" and "dot". That should axe the hung SSH session and get you back to screen.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .