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
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
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 firstname.lastname@example.org
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.
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 188.8.131.52 PING 184.108.40.206 (220.127.116.11) 56(84) bytes of data. 64 bytes from 18.104.22.168: icmp_req=1 ttl=57 time=18.2 ms 64 bytes from 22.214.171.124: icmp_req=2 ttl=57 time=17.2 ms 64 bytes from 126.96.36.199: 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 188.8.131.52: icmp_req=203 ttl=57 time=18.2 ms 64 bytes from 184.108.40.206: icmp_req=204 ttl=57 time=18.1 ms 64 bytes from 220.127.116.11: icmp_req=205 ttl=57 time=18.1 ms 64 bytes from 18.104.22.168: icmp_req=206 ttl=57 time=18.4 ms 64 bytes from 22.214.171.124: icmp_req=207 ttl=57 time=18.1 ms ^C --- 126.96.36.199 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.