Ssh – How to safely resume an aptitude dist-upgrade after SSH timeout

To get closer to a definitive answer for this, we need to see which files are causing the mount: / is busy error. You could do this with:

lsof / | awk 'NR==1 || $4~/[0-9][uw]/'

See my answer to the OP's other question - lsof: show files open as read-write - for the caveats to this. It may be that you need to put this into a separate script and the put the script into the apt hook in order to see something.

My suspicion is that files under /etc remain open once the services are started. Some programs/daemons update their configuration dynamically. NetworkManager and cupsd are two examples. Updates to cups which cause cupsd to scan for new printers (as opposed to a dpkg configuration script) may well be what is causing your issue. I recommend that you put /etc on a writeable file system, even if it is not the source of your problem.

Another possibility is that the filesystem buffer is still in the process of being flushed to disk when you try to do the remount. I'm not sure what the behaviour for mount is here, whether it is to block until IO is complete or to fail and report the disk as busy. The first seems more likely, but I see no sync calls in the output of strace (although possibly the mount system call does this). Anyway, it may work to do a sync before the remount if the lsof above doesn't show anything, eg:

DPkg::Post-Invoke { "sync; mount -o remount /"; };

Writing to /dev/tty does not take the process-id into account; you will not succeed in that way.

Although it is the same device, there are different file-descriptors which a process will have open on a given device. For Linux, you can manipulate the separate file-descriptors if you know the process-id, i.e., /proc/PID/fd/0 is the standard input for the process whose id is PID.

For your case, the program is opening the device, and its file-descriptor would also be in /proc/PID/fd (but not as well identified). An application could "see" the symlink information from within that directory, and manipulate it.

If you look closely, the items in /proc/PID/fd all have different inode values (because they are different file descriptors). Echoing to the entry in proc/PID/fd means you are echoing to that file descriptor.

But ssh is not expecting input from that direction, has no provision for supplementary prompts - a workaround such as you are using is probably the best you'll be able to do.