Gracefully killing "stuck" SSH sessions

On my home WiFi connection, I occasionally find my SSH sessions being stuck and completely unresponsive. The only way to resolve the issue has been to close the window of the terminal emulator, which is usually no big deal. This becomes more of an issue when using ChromeOS on my CR48 where you can't close the shell window by any means other than the "exit" command. Prior to discovering a more graceful solution, I had been using this somewhat lengthy workaround (which requires ChromeOS to be in dev mode):

  • Press Alt-Ctrl-T to open a new crosh shell.
  • Type "shell" to open a Linux shell.
  • Run "ps fax | grep ssh" to find the process id of the stuck ssh session.
  • Kill the stuck session with "kill -9 [process ID]"
Killing the process manually is not ideal, especially when your WiFi drops whenever the router yawns.

This solution that is built into the standard openSSH client takes a lot less time and closes the connection as opposed to just killing the client process. When the session is stuck, press the following keys to close the SSH connection:

  • Enter
  • Tilde ( "~" / shift back-tick )
  • Period
That's it! Your connection will be closed with the "Connection to [host] closed" message. I hope that you find this tip as useful as I did. Happy hacking!

Gracefully killing "stuck" SSH sessions

On my home WiFi connection, I occasionally find my SSH sessions being stuck and completely unresponsive. The only way to resolve the issue has been to close the window of the terminal emulator, which is usually no big deal. This becomes more of an issue when using ChromeOS on my CR48 where you can't close the shell window by any means other than the "exit" command. Prior to discovering a more graceful solution, I had been using this somewhat lengthy workaround (which requires ChromeOS to be in dev mode):

  • Press Alt-Ctrl-T to open a new crosh shell.
  • Type "shell" to open a Linux shell.
  • Run "ps fax | grep ssh" to find the process id of the stuck ssh session.
  • Kill the stuck session with "kill -9 [process ID]"
Killing the process manually is not ideal, especially when your WiFi drops whenever the router yawns.

This solution that is built into the standard openSSH client takes a lot less time and closes the connection as opposed to just killing the client process. When the session is stuck, press the following keys to close the SSH connection:

  • Enter
  • Tilde ( "~" / shift back-tick )
  • Period
That's it! Your connection will be closed with the "Connection to [host] closed" message. I hope that you find this tip as useful as I did. Happy hacking!

Gracefully killing "stuck" SSH sessions

On my home WiFi connection, I occasionally find my SSH sessions being stuck and completely unresponsive. The only way to resolve the issue has been to close the window of the terminal emulator, which is usually no big deal. This becomes more of an issue when using ChromeOS on my CR48 where you can't close the shell window by any means other than the "exit" command. Prior to discovering a more graceful solution, I had been using this somewhat lengthy workaround (which requires ChromeOS to be in dev mode):

  • Press Alt-Ctrl-T to open a new crosh shell.
  • Type "shell" to open a Linux shell.
  • Run "ps fax | grep ssh" to find the process id of the stuck ssh session.
  • Kill the stuck session with "kill -9 [process ID]"
Killing the process manually is not ideal, especially when your WiFi drops whenever the router yawns.

This solution that is built into the standard openSSH client takes a lot less time and closes the connection as opposed to just killing the client process. When the session is stuck, press the following keys to close the SSH connection:

  • Enter
  • Tilde ( "~" / shift back-tick )
  • Period
That's it! Your connection will be closed with the "Connection to [host] closed" message. I hope that you find this tip as useful as I did. Happy hacking!

Gracefully killing "stuck" SSH sessions

On my home WiFi connection, I occasionally find my SSH sessions being stuck and completely unresponsive. The only way to resolve the issue has been to close the window of the terminal emulator, which is usually no big deal. This becomes more of an issue when using ChromeOS on my CR48 where you can't close the shell window by any means other than the "exit" command. Prior to discovering a more graceful solution, I had been using this somewhat lengthy workaround (which requires ChromeOS to be in dev mode):

  • Press Alt-Ctrl-T to open a new crosh shell.
  • Type "shell" to open a Linux shell.
  • Run "ps fax | grep ssh" to find the process id of the stuck ssh session.
  • Kill the stuck session with "kill -9 [process ID]"
Killing the process manually is not ideal, especially when your WiFi drops whenever the router yawns.

This solution that is built into the standard openSSH client takes a lot less time and closes the connection as opposed to just killing the client process. When the session is stuck, press the following keys to close the SSH connection:

  • Enter
  • Tilde ( "~" / shift back-tick )
  • Period
That's it! Your connection will be closed with the "Connection to [host] closed" message. I hope that you find this tip as useful as I did. Happy hacking!

Gracefully killing "stuck" SSH sessions

On my home WiFi connection, I occasionally find my SSH sessions being stuck and completely unresponsive. The only way to resolve the issue has been to close the window of the terminal emulator, which is usually no big deal. This becomes more of an issue when using ChromeOS on my CR48 where you can't close the shell window by any means other than the "exit" command. Prior to discovering a more graceful solution, I had been using this somewhat lengthy workaround (which requires ChromeOS to be in dev mode):

  • Press Alt-Ctrl-T to open a new crosh shell.
  • Type "shell" to open a Linux shell.
  • Run "ps fax | grep ssh" to find the process id of the stuck ssh session.
  • Kill the stuck session with "kill -9 [process ID]"
Killing the process manually is not ideal, especially when your WiFi drops whenever the router yawns.

This solution that is built into the standard openSSH client takes a lot less time and closes the connection as opposed to just killing the client process. When the session is stuck, press the following keys to close the SSH connection:

  • Enter
  • Tilde ( "~" / shift back-tick )
  • Period
That's it! Your connection will be closed with the "Connection to [host] closed" message. I hope that you find this tip as useful as I did. Happy hacking!

Exploring Perl

Throughout my years of programming, I have heard abundant praise about the Perl language.  On the other hand, I've known some programmers that refuse to touch Perl with a ten foot pole.  Python had been my scripting language of choice in the past. Regardless, I decided it was in my best interest as a programmer to at least be familiar with the language.

After some quality time with "man perlintro", I began to get fairly comfortable with the syntax.  Diving into "man perlretut" really opened my mind to ways to parse text in new ways with regular expressions instead of complicated code chock-full of nested loops and loads of conditionals that are quite frankly awkward to code.  Another great thing about regular expressions is that many other languages and programs have support for them or a similar syntax (python re and vim for starters). I highly recommend any programmer with some spare time to check out the perlintro and perlretut manpages if they haven't already.

I wanted to dive into a bit of web programming with Perl, so I installed and configured mod_perl for my apache2 server on my Linode.  On Arch Linux, you can install mod_perl with:

pacman -S mod_perl

I added the following entry to my httpd.conf file to enable mod_perl:

<Files ~ ".(pl|cgi)$"> PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlSendHeader On </Files>

Your mileage may vary with your distribution and version of everything, but that was enough to get me started with mod_perl and apache2.

My first script was a warsow server status checker for my warsow server. You can check it out here and the source can be found here. The script is pretty simple, it basically scrapes the output of qstat (a command-line program to query quake/warsow servers) and formats the output into an HTML friendly format. Regex is used to parse the qstat output into variables that can be used to form the HTML friendly output. The code probably isn't as optimal as it could be -- for anyone checking out the source keep in mind that I was learning everything about the language and regex as I was writing this. The output of the script is currently bare-bones HTML, but with CSS added the output could also be easily improved to be more eye-friendly. Maybe one day I will extend this script further, but as it stands it was a great learning experience and still serves a useful purpose. I'm looking forward to learning more Perl and regex; I feel as if I am only scratching the surface of how much these tools will make my life easier as a programmer.

Exploring Perl

Throughout my years of programming, I have heard abundant praise about the Perl language.  On the other hand, I've known some programmers that refuse to touch Perl with a ten foot pole.  Python had been my scripting language of choice in the past. Regardless, I decided it was in my best interest as a programmer to at least be familiar with the language.

After some quality time with "man perlintro", I began to get fairly comfortable with the syntax.  Diving into "man perlretut" really opened my mind to ways to parse text in new ways with regular expressions instead of complicated code chock-full of nested loops and loads of conditionals that are quite frankly awkward to code.  Another great thing about regular expressions is that many other languages and programs have support for them or a similar syntax (python re and vim for starters). I highly recommend any programmer with some spare time to check out the perlintro and perlretut manpages if they haven't already.

I wanted to dive into a bit of web programming with Perl, so I installed and configured mod_perl for my apache2 server on my Linode.  On Arch Linux, you can install mod_perl with:

pacman -S mod_perl

I added the following entry to my httpd.conf file to enable mod_perl:

<Files ~ ".(pl|cgi)$"> PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlSendHeader On </Files>

Your mileage may vary with your distribution and version of everything, but that was enough to get me started with mod_perl and apache2.

My first script was a warsow server status checker for my warsow server. You can check it out here and the source can be found here. The script is pretty simple, it basically scrapes the output of qstat (a command-line program to query quake/warsow servers) and formats the output into an HTML friendly format. Regex is used to parse the qstat output into variables that can be used to form the HTML friendly output. The code probably isn't as optimal as it could be -- for anyone checking out the source keep in mind that I was learning everything about the language and regex as I was writing this. The output of the script is currently bare-bones HTML, but with CSS added the output could also be easily improved to be more eye-friendly. Maybe one day I will extend this script further, but as it stands it was a great learning experience and still serves a useful purpose. I'm looking forward to learning more Perl and regex; I feel as if I am only scratching the surface of how much these tools will make my life easier as a programmer.

Exploring Perl

Throughout my years of programming, I have heard abundant praise about the Perl language.  On the other hand, I've known some programmers that refuse to touch Perl with a ten foot pole.  Python had been my scripting language of choice in the past. Regardless, I decided it was in my best interest as a programmer to at least be familiar with the language.

After some quality time with "man perlintro", I began to get fairly comfortable with the syntax.  Diving into "man perlretut" really opened my mind to ways to parse text in new ways with regular expressions instead of complicated code chock-full of nested loops and loads of conditionals that are quite frankly awkward to code.  Another great thing about regular expressions is that many other languages and programs have support for them or a similar syntax (python re and vim for starters). I highly recommend any programmer with some spare time to check out the perlintro and perlretut manpages if they haven't already.

I wanted to dive into a bit of web programming with Perl, so I installed and configured mod_perl for my apache2 server on my Linode.  On Arch Linux, you can install mod_perl with:

pacman -S mod_perl

I added the following entry to my httpd.conf file to enable mod_perl:

<Files ~ ".(pl|cgi)$"> PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlSendHeader On </Files>

Your mileage may vary with your distribution and version of everything, but that was enough to get me started with mod_perl and apache2.

My first script was a warsow server status checker for my warsow server. You can check it out here and the source can be found here. The script is pretty simple, it basically scrapes the output of qstat (a command-line program to query quake/warsow servers) and formats the output into an HTML friendly format. Regex is used to parse the qstat output into variables that can be used to form the HTML friendly output. The code probably isn't as optimal as it could be -- for anyone checking out the source keep in mind that I was learning everything about the language and regex as I was writing this. The output of the script is currently bare-bones HTML, but with CSS added the output could also be easily improved to be more eye-friendly. Maybe one day I will extend this script further, but as it stands it was a great learning experience and still serves a useful purpose. I'm looking forward to learning more Perl and regex; I feel as if I am only scratching the surface of how much these tools will make my life easier as a programmer.

Exploring Perl

Throughout my years of programming, I have heard abundant praise about the Perl language.  On the other hand, I've known some programmers that refuse to touch Perl with a ten foot pole.  Python had been my scripting language of choice in the past. Regardless, I decided it was in my best interest as a programmer to at least be familiar with the language.

After some quality time with "man perlintro", I began to get fairly comfortable with the syntax.  Diving into "man perlretut" really opened my mind to ways to parse text in new ways with regular expressions instead of complicated code chock-full of nested loops and loads of conditionals that are quite frankly awkward to code.  Another great thing about regular expressions is that many other languages and programs have support for them or a similar syntax (python re and vim for starters). I highly recommend any programmer with some spare time to check out the perlintro and perlretut manpages if they haven't already.

I wanted to dive into a bit of web programming with Perl, so I installed and configured mod_perl for my apache2 server on my Linode.  On Arch Linux, you can install mod_perl with:

pacman -S mod_perl

I added the following entry to my httpd.conf file to enable mod_perl:

<Files ~ ".(pl|cgi)$"> PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlSendHeader On </Files>

Your mileage may vary with your distribution and version of everything, but that was enough to get me started with mod_perl and apache2.

My first script was a warsow server status checker for my warsow server. You can check it out here and the source can be found here. The script is pretty simple, it basically scrapes the output of qstat (a command-line program to query quake/warsow servers) and formats the output into an HTML friendly format. Regex is used to parse the qstat output into variables that can be used to form the HTML friendly output. The code probably isn't as optimal as it could be -- for anyone checking out the source keep in mind that I was learning everything about the language and regex as I was writing this. The output of the script is currently bare-bones HTML, but with CSS added the output could also be easily improved to be more eye-friendly. Maybe one day I will extend this script further, but as it stands it was a great learning experience and still serves a useful purpose. I'm looking forward to learning more Perl and regex; I feel as if I am only scratching the surface of how much these tools will make my life easier as a programmer.

Exploring Perl

Throughout my years of programming, I have heard abundant praise about the Perl language.  On the other hand, I've known some programmers that refuse to touch Perl with a ten foot pole.  Python had been my scripting language of choice in the past. Regardless, I decided it was in my best interest as a programmer to at least be familiar with the language.

After some quality time with "man perlintro", I began to get fairly comfortable with the syntax.  Diving into "man perlretut" really opened my mind to ways to parse text in new ways with regular expressions instead of complicated code chock-full of nested loops and loads of conditionals that are quite frankly awkward to code.  Another great thing about regular expressions is that many other languages and programs have support for them or a similar syntax (python re and vim for starters). I highly recommend any programmer with some spare time to check out the perlintro and perlretut manpages if they haven't already.

I wanted to dive into a bit of web programming with Perl, so I installed and configured mod_perl for my apache2 server on my Linode.  On Arch Linux, you can install mod_perl with:

pacman -S mod_perl

I added the following entry to my httpd.conf file to enable mod_perl:

<Files ~ ".(pl|cgi)$"> PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlSendHeader On </Files>

Your mileage may vary with your distribution and version of everything, but that was enough to get me started with mod_perl and apache2.

My first script was a warsow server status checker for my warsow server. You can check it out here and the source can be found here. The script is pretty simple, it basically scrapes the output of qstat (a command-line program to query quake/warsow servers) and formats the output into an HTML friendly format. Regex is used to parse the qstat output into variables that can be used to form the HTML friendly output. The code probably isn't as optimal as it could be -- for anyone checking out the source keep in mind that I was learning everything about the language and regex as I was writing this. The output of the script is currently bare-bones HTML, but with CSS added the output could also be easily improved to be more eye-friendly. Maybe one day I will extend this script further, but as it stands it was a great learning experience and still serves a useful purpose. I'm looking forward to learning more Perl and regex; I feel as if I am only scratching the surface of how much these tools will make my life easier as a programmer.