SUMMARY, STEPS TO PRODUCE AND OBSERVED RESULT It seems there'is a problem with the new feature in "Updates" which bundles packages under the name "System Upgrade", requiring computer reboot, and then performs package updates in a special new black splash screen, followed by grup update and system reboot. Today I've received this type of notification, and saw that actually there were only 3 packages of a minor application (gtk-based Font-Manager) involved. I went along with it, and the procedure was the same: I was logged out, presented with this new black splash screen informing the progress of updates only in terms of percentage, then updating grub behind the scenes (I know this because I have several customizations in the grub menu, and finally rebooting the computer. EXPECTED RESULT Only updates to packages that really require rebooting to take effect (e.g. kernel updates) should be treated as "System Upgrade", and all others should be treated different. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.21 KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2
This is sadly not something we can do as is as we don't have such information.
Moving to Neon; I guess they could make that work in their packaging. I know suse's packaging is capable of knowing which packages require a reboot and which ones don't.
Can you outline heuristics for what requires a reboot and what does not?
*** Bug 435623 has been marked as a duplicate of this bug. ***
No, it's not a neon issue. It probably is a PackageKit issue. And to be honest, I don't even know if it's doable. But as is, PackageKit doesn't have the ability to tell us "this will need updating". It just has the ability of telling "after all these updates I've done, now an update is needed". Which doesn't help since it's only issued after the fact.
Mind you that "yo, I need an update now, after I've done all this work" is really a guess and wrong 90% of the time. Packagekit also has no real heuristics, between plugin systems and runtime dlopen()ing literally anything may be impaired by a live upgrade.
So I suppose this would require several parts: 1. Somehow in the Neon/Ubuntu packaging, you would mark relevant packages with some flag saying "this will require a reboot when it gets updated" or something like that. 2. PackageKit would gain the ability to consume that information, and communicate to the app "one or more packages in this set of updates will require a reboot". 3. Discover would consumes that information and only schedules a reboot if it gets that information.
(In reply to Nate Graham from comment #7) > So I suppose this would require several parts: > > 1. Somehow in the Neon/Ubuntu packaging, you would mark relevant packages > with some flag saying "this will require a reboot when it gets updated" or > something like that. That is everything surely. Every single KDE application does load plugins at runtime or talks to daemons at runtime that may go off the compatibility rails in a update. Qt styles, KIO works, KIOd, kded, kacitivitymanagerd, baloo daemon, kparts, phonon backends, and so on and so on.
(In reply to Nate Graham from comment #7) > 3. Discover would consumes that information and only schedules a reboot if > it gets that information. At this point you've bricked the runtime already btw.
Okay. :) Expect a lot more of this conversation with users going forward though. :) It's a big change for people who have gotten used to in-place upgrades over the past 25 years.
The last update required two restarts. The first downloaded the packages and informed me to restart. After restarting it informed me that there was a System Update and required a reboot again after I clicked Update all. It didn't download anything on the second restart as the packages were already downloaded, it just rebooted and installed the packages. It did contain a kernel update, but still should've taken only one restart. (In reply to Aleix Pol from comment #5) > No, it's not a neon issue. It probably is a PackageKit issue. And to be > honest, I don't even know if it's doable. It really should be figured out and made doable. Rebooting the system, AFAIC, should only be done for things that cannot be safely restarted (kernel updates, filesystem libraries, etc), all other's should just require restarting the service (Plasma, xwin, wayland, audio, whatever) or simply just reloading the driver. Rebooting for a simple application installation/update is absolutely ridiculous. If this is really resolved with no resolution other than "just deal with it", then perhaps it's time to use Discover only for notification of an update and use Synaptic or aptitude to perform the actual installation.
(In reply to lnxusr from comment #11) > If this is really resolved with no resolution other than "just deal with > it", then perhaps it's time to use Discover only for notification of an > update and use Synaptic or aptitude to perform the actual installation. With my "Usability & Productivity" hat on, I must point out that this is what can happen when we annoy the users "for their own good" in a free system. They can always just get the mostly-less-annoying-but-theotetically-dangerous behavior back again. We can say, "well, not my responsibility then" but in that case we're still failing at our ultimate goal of protecting these users from broken systems post-upgrade. The same thing happened when we prohibited running Dolphin with sudo: people who wanted to do it got annoyed and just used Thunar or Nemo instead, easily bypassing our desire to protect them, and driving them away from our software. :(
(In reply to Nate Graham from comment #12) > With my "Usability & Productivity" hat on, I must point out that this is > what can happen when we annoy the users "for their own good" in a free > system. I don't care to be annoyed "for my own good", I prefer to be educated to the issues and allowed to continue if I so desire. > They can always just get the mostly-less-annoying-but-theotetically-dangerous > behavior back again. We can say, "well, not my responsibility then" but in > that case we're still failing at our ultimate goal of protecting these users > from broken systems post-upgrade. Freedom and customization is what GNU/Linux and, one would hope, KDE/Plasma is all about; or at least it used to be. > The same thing happened when we prohibited running Dolphin with sudo: people > who wanted to do it got annoyed and just used Thunar or Nemo instead, easily > bypassing our desire to protect them, and driving them away from our > software. :( I prefer MC in the console or Krusader, so never noticed the inability to run Dolphin with sudo. If I had, I most certainly would've filed a bug report. I am not a child that need to be protected from my own actions. I've was using Linux back when KDE was in it's infancy and needed to be compiled from source to use, and have more than once inadvertently broken it beyond repair (deleted the root partition type of broken). I'm well aware of what my actions can do to my system and would never blame the software for something that is clearly my own fault. Now that I understand the reasoning behind restarting with system updates, I'll be more apt to restart at days end, but the double restart issue I mentioned above may be something to look into. I prefer to suspend my system at the end of the day because not everything gets restarted and/or put back in it's previous state on a restart so it takes me a few minutes after a restart to get back to a productive state. I apologize for this long rant, but your "for their own good" and "bypassing our desire to protect them" statements triggered me. I use Linux and KDE because it offers me the freedom to use my computer the way I want, and I'm sure a great many users feel the same.
> but the double restart issue I mentioned above may be something to look into Yes, maybe file a separate bug report for that. It doesn't sound right to me. > I apologize for this long rant, but your "for their own good" and "bypassing > our desire to protect them" statements triggered me. I use Linux and KDE > because it offers me the freedom to use my computer the way I want, and I'm > sure a great many users feel the same. I understand completely. However we are attempting to make a system that works for regular people, not just nerds like us. :) And we can't assume that regular people will understand these risks, even if we attempt tp educate the. I'm all in favor of choice too, and would probably advocate for offline updates to be the default UX, but disable-able for experts like you who understand the risks. Maybe this is already possible in fact, but I don't know how it would be done.
*** Bug 435703 has been marked as a duplicate of this bug. ***
JFYI, we are working on a way to make this optional: https://invent.kde.org/plasma/discover/-/merge_requests/111
(In reply to Nate Graham from comment #16) > JFYI, we are working on a way to make this optional: > https://invent.kde.org/plasma/discover/-/merge_requests/111 Is there a way to grab the restart notification? I'd still like to suspend my system nightly, but I'd like to make a script that will notify me before suspending if there's a pending restart so I can handle what I need to and just shut down for the night.
> They can always just get the mostly-less-annoying-but-theotetically-dangerous > behavior back again. > We can say, "well, not my responsibility then" but in that case we're still > failing at our ultimate goal of protecting these users from broken systems > post-upgrade. Yes, good point. If live updates are that risky it's probably better not to do it, because a broken system is the bigger problem than the time overhead needed at reboot. However, I personally didn't have an issue with it so far. > all others should just require restarting the service (Plasma, xwin, wayland, > audio, whatever) or simply reloading the driver Althogh I know almost nothing about the system internals, this sounds like a good idea to me, although it's probably very difficult. As far as I know, there even is some kernel livepatch service that is used for servers to avoid long reboots, so maybe something similar is theoretically possible for plasma, daemons, ..., too?
Git commit 8464bec59dd3b05485897c97663fbe28267fc449 by Aleix Pol. Committed on 15/04/2021 at 00:50. Pushed by apol into branch 'master'. kcm: Add a configuration setting for offline updates Lets users who prefer unstable systems to rebootting keep their old ways. Lets users from distros that don't enable it by default, enable it and enjoy a more stable upgrade experience. M +8 -0 kcm/CMakeLists.txt A +18 -0 kcm/discoversettings.kcfg A +11 -0 kcm/discoversettings.kcfgc M +38 -0 kcm/package/contents/ui/main.qml M +10 -0 kcm/updates.cpp M +5 -0 kcm/updates.h https://invent.kde.org/plasma/discover/commit/8464bec59dd3b05485897c97663fbe28267fc449
Re: comment #1 "We don't have such information (to know if a restart is required or not)" PackageKit presumably does (depending on backend support of course): https://blogs.gnome.org/hughsie/2007/08/23/packagekit-requiring-a-restart/ Or at least it did at one time, I don't know it's current state as that post is pretty old. That said, I do agree with the general consensus that offline updates is a better option in most scenarios.
Sorry for the noise, looks like this case was covered in dialog in other bug comments here.
(In reply to Harald Sitter from comment #3) > Can you outline heuristics for what requires a reboot and what does not? Hmm, is there a list of which other packages depend on a package? Then a basic heuristic would be not to require reboot for packages that are not dependencies of other (installed) packages. This would at least allow to exclude most end-user applications, like web browsers and office applications, where a reboot should not be needed.
A definitely more complex heuristic would be to somehow check whether any binary provided by a package to be updated is currently in use. If it is not, the update could be performed without reboot, but then it would be necessary to inhibit launching new applications that do depend on it until the update is finished.
(In reply to Manuel Geißer from comment #22) > (In reply to Harald Sitter from comment #3) > > Can you outline heuristics for what requires a reboot and what does not? > Hmm, is there a list of which other packages depend on a package? Then a > basic heuristic would be not to require reboot for packages that are not > dependencies of other (installed) packages. This would at least allow to > exclude most end-user applications, like web browsers and office > applications, where a reboot should not be needed. That info is already available in every .deb package, it just needs to be gathered and stored in a central location to prevent having to check each individual package needing updating. There would also need to be a way to grab that data when a package manager other than Discover was used to install a package.
(In reply to Rex Dieter from comment #20) > Re: comment #1 > > "We don't have such information (to know if a restart is required or not)" > > PackageKit presumably does (depending on backend support of course): > https://blogs.gnome.org/hughsie/2007/08/23/packagekit-requiring-a-restart/ > > Or at least it did at one time, I don't know it's current state as that post > is pretty old. > > That said, I do agree with the general consensus that offline updates is a > better option in most scenarios. PackageKit still supports this, but most backends just don't bother to set the information whether restart is required and basically set it to not required unconditionally. Consequently, no frontends care about that information and don't use it for deciding whether a reboot is required.
Re-opening since I think we may have a narrow path forward: - Make use of the existing "needs reboot" flag, if it's set - Encourage distros and packagers to set it more often - Try to determine for ourselves whether a reboot is requires by cross-referencing the binaries/files that a package update has installed with the list of open files; an update that has changes files none of which are currently open does not require a reboot
So Fedora already offers the "reboot_suggested" flag for updates published in Fedora. I've sent a PR to Bodhi (the updates submission and publishing system) to also add support for application restart (reload) and user logout+login (relogin) flags as specified in RPM updateinfo metadata: https://github.com/fedora-infra/bodhi/pull/4214 I'm currently working on libdnf to add an API for PackageKit-DNF to consume.
libdnf bug for reference: https://bugzilla.redhat.com/show_bug.cgi?id=1959022
Blech, I misunderstood "restart" state, but I'm working on reboot + relogin. Once I have an implementation for this in the DNF backend, I can give advice of how to interpret it from PackageKit.
*** Bug 438393 has been marked as a duplicate of this bug. ***
(In reply to Aleix Pol from comment #19) > kcm: Add a configuration setting for offline updates Awesome, thanks a lot! This was really annoying for applications with frequent updates, e.g. browsers, messengers.
Interesting observation: I've use the config option to return to immediate update and just had bunch of new KDE packages come through. They were separated into "Application Updates", "Addons" and "System Updates". So it seems that at least the apt/dpkg backend has the necessary information to apply application updates without reboot
(In reply to Kevin Krammer from comment #32) > Interesting observation: I've use the config option to return to immediate > update and just had bunch of new KDE packages come through. > > They were separated into "Application Updates", "Addons" and "System > Updates". > > So it seems that at least the apt/dpkg backend has the necessary information > to apply application updates without reboot That information exists in the dnf backend too, because that's AppStream data. However, the AppStream data does *not* tell you whether the programs are running, or whether they're critical to the system. Nor does it tell you whether the update being pushed has been marked as one that requires a reboot or relogin. That information is important for doing this right.
(In reply to Neal Gompa from comment #33) > Nor does it tell you > whether the update being pushed has been marked as one that requires a > reboot or relogin. Yes, sorry, I did not intend to imply that this information was fully equivalent. But it could still be used to install application-only update sets without reboot. In the case of my most recent update the presence of KDE framework updates would have still caused an unneeded reboot. However in the update that triggered my initial bug report, the single google-chrome" package would not have. In any case the config option solves the problem for me. I know to reboot when the update contains the Linux kernel, systemd or grub. It was just very annoying to have to go back to aptitude/apt after having used Discover for quite a while.
*** Bug 440126 has been marked as a duplicate of this bug. ***
As the originator of a bug report marked as a duplicate of this, I have just been asked how the Discover developers can identify updates requiring a reboot. Since this is not an area of expertise of mine I have no idea. However, as I mentioned in my report, the server management program "Cockpit" *does* do this, as well as identifying daemons that need restarting, in the same environment. It's open source so perhaps you can just see how they do it. https://cockpit-project.org/
(In reply to Mark Stanton from comment #36) > As the originator of a bug report marked as a duplicate of this, I have just > been asked how the Discover developers can identify updates requiring a > reboot. > > Since this is not an area of expertise of mine I have no idea. However, as I > mentioned in my report, the server management program "Cockpit" *does* do > this, as well as identifying daemons that need restarting, in the same > environment. > > It's open source so perhaps you can just see how they do it. > > https://cockpit-project.org/ Cockpit *can* do this if Tracer[1] is installed, and otherwise falls back to the same behavior Discover has. [1]: http://tracer-package.com/
For reference, the logic for this is entirely contained in this file in Cockpit: https://github.com/cockpit-project/cockpit/blob/main/pkg/packagekit/updates.jsx (Warning, React-flavored JavaScript is used here...)
I'm not aware of having installed Tracer so presumably Cockpit did it? I notice also that Cockpit implements the very technical and sophisticated "Ignore" option, allowing those who feel they have a clue better control of their environment.
I took a look at Tracer. I installed it from source on Neon User, but it doesn't really work, searching for outdated packages fails with a NotImplementedError and showing specific packages with a FileNotFoundError. Anyway, I don't quite understand what use Tracer should be for this problem. for it only finds running outdated applications, with outdated meaning that an in-memory binary is different from its on-disk equivalent. This is a post-update tool only. What we would need, however, is a logic to determine beforehand whether a package can be safely updated in the background during the running session, or whether the update must to be applied upon reboot.
*** Bug 442637 has been marked as a duplicate of this bug. ***
I can't believe that one year has elapsed since this issue was reported without any move towards some solution,y improvement etc. while a lot of development effort is being spent on many cosmetic enhancements here and there. I wish I had some programming skills to contribute to development. Isn't it possible to determine of all the packages installed which ones have some component running when the user logged in? Then, any pending package update could be compared with such a list to decide if any update should better be performed after the user logs off, and even as another level, after the computer reboots. Furthermore, some processes/apps started after the user logged in may just need to be stopped and restarted after an update affecting them is performed without even logging off. This sounds quite logical to me, although I'm also prepared to accept that this is just due to my complete ignorance in programming, in which case I apologize for my impatience. I can of course continue looking at the list first and make that decision myself and then performing some updates by quitting Discovery and launching my package manager...
This mostly needs to be changed in PackageKit itself, which is what provides all of the relevant functionality. I'm not sure Discover itself has the ability to request an offline update for only certain distro packages, but let other distro packages be updated interactively.
I'd be happy with a simple "Install Now" tickbox that I could enable once I've looked over the packages to be upgraded and determined a reboot isn't necessary. Heck, I don't even bother rebooting for kernel updates, since it's not like it affects the currently running kernel in any way. I'll just end up on the new kernel next time I start up my PC. Most of the time, my daily upgrade regimen is as follows: 1. Look over list of updates in Discover. 2. Notice that the packages to be upgraded are various apps that I'm not currently running. 3. Untick the box for "System upgrade" while leaving all the Snap and Flatpak apps selected, then hitting "Update All" 4. Pull down Yakuake and run "pkcon update" to grab and install repository updates immediately. I leave offline updates enabled, though, because when I see a bunch of KDE desktop upgrades or whatever, I want those to install offline.