Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 5 down vote favorite
1

I've had this problem occur at random, intermittently, across boxes at multiple companies, multiple distros, and multiple kernel revs. I think that I'm just cursed.

What happens is that I'll have a new box loaded, and I'll be doing something inside ssh, like a yum update or an apt-get. Everything will be progressing fine and then the session just stops. The ssh doesn't disconnect, it's almost as if someone sent a scroll lock keypress to the session.

If I hit enter, or space, or just about any keystroke in the ssh session, the session wakes back up and its as if nothing went wrong.

I once upon a time tracked down an issue like this and found that the interactive processes were entering SLEEP status. I can't confirm that this is the same behavior in this case, but I will amend the question if I can pinpoint that specific cause.

Regardless, I was never able to figure out why the processes were randomly going into sleep.

Has anyone had this or a similar issue and have any insight into what might be causing it?

share|improve this question
4  
Sleep status just means there's nothing to run, not that it's Stopped. It may be interesting to attach to the process with strace when that happens and observe where it's sleeping and what happens when you press a key. – MikeyB Jul 13 '12 at 15:36
The remote endpoint is a bunch of different places, but what about the local endpoint? Is it always on the same network? If so, I put $10 on broken/misconfigured firewall on your network (or, I guess, your ISP's). Diagnose by running packet capture on both ends. – derobert Sep 12 '12 at 15:10
I cannot substantiate this claim so I won't post it as an answer, however we upgraded the boxes away from CentOS 6's -220 kernel release, and the problem went away for all boxes. – Peter Grace Sep 12 '12 at 21:28

1 Answer

up vote 1 down vote

I once had something similar. Turns out the TCP was disconnecting and then re-connecting, because the MTU on the session was bad. When long output would be sent to the terminal, this is what would happen (long output means large packets means over the real MTU limit, say if you're connecting thru a tunnel).

In my case a modem reset (I was VPN'ing from home) solved it. In another similar case -- a configuration on the firewall/VPN-gateway did it.

Does this happen when there's a lot of output going to the console? If so, can you try to run tcpdump on the remote box, say to a file, and see if this is the case?

share|improve this answer
If TCP disconnects, your SSH session is over; it won't transparently reconnect. What you're describing is a classic firewall misconfiguration that breaks path MTU discovery. Normally, pressing a key (sending a packet from your side) wouldn't fix that, but who knows. Its certainly possible this is OP's problem. – derobert Sep 12 '12 at 15:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.