How to kill an unresponsive ssh session(laszlo.nu)
laszlo.nu
How to kill an unresponsive ssh session
http://www.laszlo.nu/post/553591402/how-to-kill-an-unresponsive-ssh-session
12 comments
It's like people don't know about man pages anymore. Google is the man page... only you may not get your answer on the first try.
You can add Unix Manpages to your "Subscribed Links" in your Google preferences, and then you will get your answer on the first try.
Thanks!
They do but nobody wants to memorize everything off some man page. There are thousands and generally, man pages are considered references where you dig up one thing at a time.
Then there are man pages that are actually being studied with great care, such as bash. And even bash man page is notorious for containing an endless amount of information. You can read it several times and still you will bump into a blog post or HN comment that reveals some previously missed (but documented) bash feature.
Telnet conveniently prints "Escape character is ^]" and that's why everybody knows it. I must admit it probably never occurred to me that ssh must have some sort of escaping method as well.
Well, thanks to HN for that link anyway :)
Then there are man pages that are actually being studied with great care, such as bash. And even bash man page is notorious for containing an endless amount of information. You can read it several times and still you will bump into a blog post or HN comment that reveals some previously missed (but documented) bash feature.
Telnet conveniently prints "Escape character is ^]" and that's why everybody knows it. I must admit it probably never occurred to me that ssh must have some sort of escaping method as well.
Well, thanks to HN for that link anyway :)
On rare occasion, Google does give me a man page, but more often than not, someone has answered my bone-head question in simple terms in a forum somewhere.
Oh, I wasn't dissing the Google method. I'm just saying that if people bothered to read the whole manpage for some application just once, they'd know of the "cool" features they might need, instead of waiting until someone posts it on HN or reddit.
The issue being that not all manpages are created equal. Some only document 2% of the program's functionality, others drone on and on about insignificant features, others are just unclear in their wording. It makes it so that people only consult the manpages when they need to.
That said, reading the manpages for something that you use all the time like ssh is a good idea. (Though if you use zsh, I'll take a bit to go through all of the documentation)
That said, reading the manpages for something that you use all the time like ssh is a good idea. (Though if you use zsh, I'll take a bit to go through all of the documentation)
That's one reason to favor BSD over the ill-advised GNU/Linux info page movement.
The BSDs take man pages quite seriously.
The BSDs take man pages quite seriously.
People don't read documentation. I clicked on this thing thinking "No, it's can't just be about the ~ escape, right? There's some content here.... Right?"
I lost. It's a blog post about a documented feature. Tune in next week for the "-j" option to tar!
I lost. It's a blog post about a documented feature. Tune in next week for the "-j" option to tar!
Seems you haven't read your man pages recently. -j is deprecated. Yes, tar has implemented auto-detection after all these years!
tar xf linux.tar.bz2
Uh... my man page says nothing about deprecation, it just documents its behavior.
And I certainly still find it useful, in any case, for situations where autodetection won't work -- for example when you are creating an archive. Y'know, with the "-c" flag that apparently you haven't read about yet.
Bazinga!
(edit: What I find most interesting isn't so much that you goofed your snipe, which happens all the time. It's that someone upvoted it.)
And I certainly still find it useful, in any case, for situations where autodetection won't work -- for example when you are creating an archive. Y'know, with the "-c" flag that apparently you haven't read about yet.
Bazinga!
(edit: What I find most interesting isn't so much that you goofed your snipe, which happens all the time. It's that someone upvoted it.)
Try doing that on older Solaris's or AIX machines.
That can often only help if you read the documentation before you want to anything with the program in question. For problems for which you (a) already have a solution and (b) do not know that the program has a better solution for, why would you read the man page?
I think people have learned not to use man pages because the man pages in GNU land almost universally suck. Check out OpenBSD's for some examples of really good documentaion
My take on man pages is "If you want people to RTFM, make a better FM".
(not mine originally)
(not mine originally)
Be careful if you're a couple sessions deep.
The proper way to kill a session if you're connecting from one server to another is ~~. (two tildes). Otherwise you'll kill your first session and lose access to the other session you connected to from it.
Also, as others have mentioned, <ENTER> first just to make sure you're on a new line.
The proper way to kill a session if you're connecting from one server to another is ~~. (two tildes). Otherwise you'll kill your first session and lose access to the other session you connected to from it.
Also, as others have mentioned, <ENTER> first just to make sure you're on a new line.
I learn something wonderful almost every day on HN.
I just tried this, and it seems just ~. works fine (no newline needed).
I just tried this, and it seems just ~. works fine (no newline needed).
quoting from the manpage:
"The escape character is only recognized at the beginning of a line."
so you'll generally need that newline to allow the escape to be detected, even though it's not technically part of the sequence.
"The escape character is only recognized at the beginning of a line."
so you'll generally need that newline to allow the escape to be detected, even though it's not technically part of the sequence.
On a related note, for folks using PuTTY.exe on Windoze to SSH, if you sometimes accidentally hit CTRL-S and "lock up" the session, hit CTRL-Q to recover.
Apparently CTRL+S actually does XOFF, which means the terminal will accept key strokes but won’t show the output of anything. It will appear as if your terminal is dead when it’s really just waiting to be turned back on. The fix? Simply press CTRL+Q to turn flow-control on (XON). If you pressed a whole bunch of keys before pressing CTRL+Q, you’ll see the output from those keystrokes.
credit: http://raamdev.com/recovering-from-ctrls-in-putty
Apparently CTRL+S actually does XOFF, which means the terminal will accept key strokes but won’t show the output of anything. It will appear as if your terminal is dead when it’s really just waiting to be turned back on. The fix? Simply press CTRL+Q to turn flow-control on (XON). If you pressed a whole bunch of keys before pressing CTRL+Q, you’ll see the output from those keystrokes.
credit: http://raamdev.com/recovering-from-ctrls-in-putty
This is why people on IRC always say things like:
<jrockway> My net connectio*#$&*#^B^B^H~.~.~.
<jrockway> .~.
<jrockway> MY NET CONNECTION SUCKS
Why is a Scandinavian asshole blocking the article?
http://grab.by/42AG
http://grab.by/42AG
Hahaha. Sorry about that. He's gone now.
I have no idea about who Håkon Wium Lie is though. That must be some kind of misunderstanding.
Thanks for all the comments.
I have no idea about who Håkon Wium Lie is though. That must be some kind of misunderstanding.
Thanks for all the comments.
It's a collaboration between Norway and Sweden. Håkon Wium Lie from Norway did the CSS and Andre Laszlos did the coding part.
Great article btw.
Great article btw.
Any chance these sessions are just on flow control and are actually not unresponsive (Ctrl-s/Ctrl-q)?
for me this is a side effect often of starting something that hangs on to a standard in, out, or error. when starting server processes, it can be nice to do the full thing: nohup CMD > stdout.log 2> stderr.log < /dev/null &
The SSHD - at least OpenSSH's - also kills mute sessions when it notices they have been completely silent for a while.
I believe this is both configurable and not the OpenSSH default.
Your distro likely enabled this, some enjoy messing with the sshd_config. (I believe Redhat and Redhat derived distros tend to enable this setting, but it is not the openssh default behavior.)
Your distro likely enabled this, some enjoy messing with the sshd_config. (I believe Redhat and Redhat derived distros tend to enable this setting, but it is not the openssh default behavior.)
In most cases when I have seen this behavior it was not caused by sshd, but by some overly intelligent device (eg. Alcatel's ADSL modems do this) along the way.
derp.
Of course - if you're multihopping this all works as well. You'll need to add a ~ for each machine in the loop though.
E.g. if I hop from workstation -> server1 -> server 2... ~^Z drops me to workstation shell. ~~^Z drops me to server 1 shell.