While you can't reattach to a broken SSH session, you can reparent the process running inside SSH – functionally equivalent to what you want.
Instructions
In your case, you would take over the apt-get
process, with the goal to control it from a new SSH session, screen
session or the like. My favourite for this is the reptyr
command:
$ sudo apt-get install reptyr
$ ps ax | grep apt-get
10626 pts/8 R+ 0:32 apt-get upgrade
Then, with the pid you found for your process:
$ sudo reptyr -T 10626
Or if that does not work, try:
$ reptyr 10626
After this stage, all your keyboard input goes to the program you took over. Unfortunately you will not see old output of the SSH session, such as the apt-get
output asking you for confirmation.
Explanations
There are multiple other tools that basically work the same as reptyr
(that is, via ptrace
debug attachment). See the following questions and answers where they are discussed:
In the instructions above, the reptyr 10626
uses ptrace
debug attachment while the sudo reptyr -T 10626
command uses TTY stealing and is preferable (details).
Finally, the reason why you can't take over a SSH session this way is because a sshd
process is not controlled by a host terminal, instead it provides the slave part of a terminal – a pts
device – while the master part controlling it resides on the client machine, here with a broken-down SSH session in between. When you force taking over such a sshd
process with reptyr -s <pid>
, your keyboard input goes to that process, not its active child process. So a "Ctrl+Z" will simply kill off that sshd
.
apt-get
process was still running. It should have died along with the whole process chain up to SSH. I've noticed thatdo-dist-upgrade
automatically starts in ascreen
/byobu
session: maybe in some circumstances,apt-get
does the same?apt upgrade
running waiting for input while my ssh session broke. After reconnecting I killed the running apt process and then continued from last upgrade step withdpkg --configure -a
- which should complete all pending packages.