I had to suspend a running do-release-upgrade,
after it was already going on an hour or so.
Doing Ctrl+z was easy, the program did stop.
Understanding what that means, technically, seems to be more complicated. It was running since an hour or so when suspending (on a slow netbook hdd), so I don't really now the state it is in. Based on the runtime, I expected it to be in the middle of replacing packages, too late to cancel. The screen output was about unpacking individual packages - but I'm unclear whether that means "unpacking to overwrite old" as opposed to "just unpacking (to some staging area)".
To make the question and answers more generally useful, let's discuss what happens for any states the upgrade may be in, not only my particular case.
So, after suspending, I started the chromium-browser, which came up just fine. Let's assume the system will be used by an typical desktop session for some hours now.
I would not be too surprised if I can do that without problems, just send a SIGCONT to do-release-upgrade later, and watch it completing.
Even if it turns out that my system is in the middle of being replaced completely. But we have these big scary warnings from do-release-upgrade, that nothing can be stopped once it started changing the system, and I fully expect that there are things that could go really wrong.
But for now, I have not much idea what that would be, and why. Understanding that, partially or completely, seems to be helpful to recover from related problems even outside of do-release-upgrade.
Maybe we can learn something from my live case, but I also remember a similar situation where I attempted to use a GUI system during running do-release-upgrade, which was showing some interesting symptoms. The most prominent was that some fonts vanished from live running programs. It was something like the gnome panel, and also the window titles, that suddenly started drawing boxes - but did not suddenly use an updated font later. But the programs were running fine. Also, I was keeping some about dialogs of KDE programs open. They stayed open, showing the old version, even after the program had been obviously replaced. Quite possible I had stopped the old program, though.
An important aspect is certainly how a typical Linux file system works in terms of deleting files that are still kept open by running processes: The reference from opening a file, that is known inside one program only, is as good as a normal file name, when it comes to deleting a file. As long as at least one reference of either kind exists, the file is not deleted, by definition. That means it's technically no problem to keep a rogram running, update it- replacing the old version, start another instance, and see two different versions running at the same time. They should even have the same file name.
So, somehow it's surprisingly robust, but on the other hand, there certainly have to be weak points...
Things like replacing libc, or some infrastructure services... seems odd to even hope it could work!?
