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 This email address is being protected from spambots. You need JavaScript enabled to view it.
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.
