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.

Improve this question
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. Commented 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. Commented 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. Commented Nov 14, 2014 at 10:45
  • bindkey? You're using zsh? What happens if you change shells (bash)? Commented Dec 12, 2014 at 16:23

1 Answer 1

Reset to default
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.

Improve this answer
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.