Am I supposed to close all flatpak apps when executing flatpak update to avoid them crashing?
Background: I recently found a crash which seems to only happen when a webkitgtk application is running while its runtime is being updated. I was wondering whether this is a bug or not.
From dnf/rpm, I know that despite usually not causing problems, there is no guarantee that applications continue to run. Firefox therefore has introduced some mechanism which prompts users to restart Firefox if it was updated in the background. Somewhere (I don’t remember where) I was told to not execute commands like dnf update from a regular terminal in a graphical session, because the chances are nonzero that the update crashes the GUI session or the terminal running in it, which would abort dnf, potentially leaving the system in a broken state.
Is the same true for Flatpak?
And if you have an answer to my question, is this written down somewhere? I couldn’t find it
Normally apps even run after you uninstall them, as they are loaded into RAM. I think you need to restart them to even apply the update
I dont think this makes sense. Unless the update changes core components or itself, a crashing GUI should not stop dnf from running.
But atomic updates are great for this. Something that dnf Fedora still doesnt have, while atomic desktops do (but with a boatload of more stuff like immutability)
So no, flatpak apps can be upgraded any time as the upgrade will never change flatpak itself, and not the running processes. Additional processes will run updated. So simple one-process apps will just go on running, while browsers etc. will need to be restarted
I don’t know about written down, but all software apps should be closed before the supporting libraries or executables are updated. That has been a general guideline for many years. A flatpak runtime is similar to a kernel or libraries in that the app is dependent upon the stability of the runtime to continue working.
This statement is factual, but I feel it is highly overrated. The chances are nonzero but so small as to be normally insignificant. I routinely use a terminal window to do dnf updates and in over 20 years have never seen a terminal crash.
The real risk is that if the terminal software is updated it may cause the terminal to crash like your flatpak runtime caused the flatpak app to crash.
In general, when performing updates (whether from a terminal window or a text login), and particularly when the gui package manager does the automatic updates, it is best to close all apps that are not absolutely necessary until after the update completes. Note that the gui package manager and automatic updated do not require that any apps be closed before they perform updates.
Those who are strictly determined to avoid any kind of disruption should be strict about closing apps before updates. Probably 95+% of all users ignore that suggestion.
But I guess we are talking about flatpak here. If you change a flatpak app you will download it first and if the flatpak is from an other gnome version as example you will also download the new run-times for them. Then it is necessary to reboot before your system gets updated and you can use the software.
For firefox and webkit and probably other applications which rely on having multiple processes running and which start and stop them at runtime, this is clearly not true. This is the reason why firefox shows those banners: If the firefox binaries were updated on disk and firefox wants to start a new child process, the child process potentially has a different IPC API/ABI interface, which could cause crashes. Firefox handles this intelligently and bails out. Webkitgtk doesn’t and therefore breaks, both with Webkitgtk as RPM and with webkitgtk as flatpak.
My question is not whether it works or doesn’t, my question is whether there is some official statement regarding flatpak claiming one or the other, so I know whether the webkitgtk crash is a bug in webkitgtk or in flatpak.
The Fedora docs do mention that there is no need to reboot the system when upgrading an app[1], but not about the need to close/restart the app itself.
I didn’t have any issues in the past with updating Flatpaks (and their corresponding runtimes) while the apps were open (no crashes). They stayed on the old version (ovbiously) until restarted.
Which makes sense, given that they are not part of the base system. ↩︎
I suspect it is relevant as to exactly which libraries/runtimes are active and which are updated as to what the consequences may be. For safety close the app before updating, but that is not always required.
I have seen problems with chrome when an update is applied while the browser is open, and similarly for some other apps as well – but not every time.
This is meant to work; Flatpak updates should be atomic.
Your problem with webkitgtk is probably related to its use of subsandboxes to isolate browser processes. There’s a reference to that happening in a comment on a related issue from @catanzaro:
I’ve heard rumors that it might break if the runtime is updated while Epiphany is running, but I don’t think I’ve seen that happen myself.
‘Subsandbox’ is a bit of a misnomer because the new sandboxes are essentially siblings to the app’s main sandbox. Flatpak attempts to use the same runtime/app commit so that even if they’re spawned after an update, the subsandboxes should be using the same code, but this may not be working for extensions:
That could very plausibly be the bug you’re seeing. If not, please feel free to open a new issue.
The issue I’m seeing is deeply inside Webkit (HashTable/HashMap functions called from JSC), so from my outsiders perspective it looks nothing like the locale or flatpak-spawn related issues you linked, but I don’t know about WebkitGtk’s internal architecture, so I might be very wrong on this. Here is a stacktrace of the problem I’m seeing.
The problem I have described is not about the update’s atomicity. The update seems to be atomic, but the application probably crashes because of the update changing files on disk while the application is running.
