2

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.

David QC
  • 83
  • 2
  • 4
  • 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 '14 at 09: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 '14 at 09: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. – Tero Kilkanen Nov 14 '14 at 10:45
  • `bindkey`? You're using `zsh`? What happens if you change shells (`bash`)? – Signal15 Dec 12 '14 at 16:23

1 Answers1

4

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.

Community
  • 1
Signal15
  • 952
  • 7
  • 29