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.
    – 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.
    – Tero Kilkanen
    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

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.

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