SSH disconnection problem
Your terminal session may get closed due to various network issues while you are
running a process on a remote machine eg.:
# Write failed: Broken pipe
As the result of this network disconnection your ssh shell session will also inadvertently kill any child processes run under your ssh session on the remote machine.
Running an uninterrupted SSH session solution
Use the screen command to save the session. While your SSH session gets disconnected the screen command will keep your remote process running. Consider a following SSH example where we attempt to SSH from a local host 10.1.1.2 to remote 10.1.1.15 host.
Screen Command SSH Example
Let’s start by listing our currently opened screen sessions:
local> $ screen -list No Sockets found in /var/run/screen/S-lubos.
From the above screen command output we can see that currently we have no sessions opened. Let’s create a new screen session while we at the same time ssh to a remote host. Open new terminal and enter:
local> $ screen ssh root@10.1.1.15
List our screen sessions again:
local> $ screen -list
There is a screen on:
5646.pts-0.thebeast (13/05/15 16:49:30) (Attached)
1 Socket in /var/run/screen/S-lubos.
The above screen output shows that we have one session attached with PID id 5646. At this time we can start a process on a remote host as for an example we can perform a simple ping:
remote> # ping 8.8.4.4 PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data. 64 bytes from 8.8.4.4: icmp_req=1 ttl=57 time=18.2 ms 64 bytes from 8.8.4.4: icmp_req=2 ttl=57 time=17.2 ms 64 bytes from 8.8.4.4: icmp_req=3 ttl=57 time=18.0 ms
At this stage we can simulate a network disconnection to a remote host by manually unplugging network cable:
local> $ ping 10.1.1.15 PING 10.1.1.15 (10.1.1.15) 56(84) bytes of data. From 10.1.1.2 icmp_seq=9 Destination Host Unreachable From 10.1.1.2 icmp_seq=10 Destination Host Unreachable From 10.1.1.2 icmp_seq=11 Destination Host Unreachable ^C --- 10.1.1.15 ping statistics --- 13 packets transmitted, 0 received, +3 errors, 100% packet loss, time 12088ms pipe 3
At this point we have lost connection and our ssh session will freeze. We can now close the terminal window with disconnected ssh session and list our screens:
local> $ screen -list
There is a screen on:
5646.pts-0.thebeast (13/05/15 16:49:30) (Detached)
1 Socket in /var/run/screen/S-lubos.
As we can see our screen session is now detached. Next, we recreate a network connection to a remote host:
local> $ ping 10.1.1.15 PING 10.1.1.15 (10.1.1.15) 56(84) bytes of data. 64 bytes from 10.1.1.15: icmp_seq=1 ttl=64 time=0.951 ms 64 bytes from 10.1.1.15: icmp_seq=2 ttl=64 time=0.563 ms ^C --- 10.1.1.15 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.563/0.757/0.951/0.194 ms
At this point we can once again reattach to our previously opened remote ssh session:
local> $ screen -d -r 64 bytes from 8.8.4.4: icmp_req=203 ttl=57 time=18.2 ms 64 bytes from 8.8.4.4: icmp_req=204 ttl=57 time=18.1 ms 64 bytes from 8.8.4.4: icmp_req=205 ttl=57 time=18.1 ms 64 bytes from 8.8.4.4: icmp_req=206 ttl=57 time=18.4 ms 64 bytes from 8.8.4.4: icmp_req=207 ttl=57 time=18.1 ms ^C --- 8.8.4.4 ping statistics --- 207 packets transmitted, 207 received, 0% packet loss, time 206310ms rtt min/avg/max/mdev = 17.231/18.369/23.795/0.571 ms
The above output with 0% packet loss is a proof that even we’ve got disconnected from a remote session by a network failure the screen command kept out remote process alive without an interruption.