Somebody that knows underpinnings of Gnome Software better than me might correct me or shed some more light on the situation, but Gnome software itself is in the background using something called PackageKit which is not exactly the same as dnf. Choice to restart the service automatically or not, is done there I believe.
If I was the one designing the system I would rather have it just prompt and let the user decide than automatically restart the service and possibly ruin someones day (if some unsaved work is lost).
That’s my experience as well. When I get a notification from Gnome Software that there are updates to be installed, I just open a terminal and run sudo dnf update. That usually works well enough, and if there’s a kernel upgrade, I can decide when to reboot.
However, I have noticed in the past, that upgrading like that can cause occasional breakage in the desktop environment (like lost access to the GNOME keyring, font issues, keyboard shortcuts not working, etc.). Not sure whether that is due to background components crashing hard, or restarting and losing sync with other (desktop) processes. If anything like that happens, I usually just go for the reboot anyway.
Especially for less experienced users, the offline upgrade route is the safest (and it allows them to take a coffee break, speaking of which… ).
The basic point is this: updates without reboots can be unpredictable. Yes, in many cases a single service can be restarted and the system can continue to function. However, there are plenty of cases where this is not true. One example is when a low-level library is updated. There’s really no way to know which services might actually need to be updated (they might not depend on the library directly, but through some other dependency).
Furthermore, there are some (unusual, but valid) cases where the system might not even be in a reasonable state to perform the update. For example, if you’ve been playing around with mount points at all, you might be applying changes to the wrong partition. GNOME Software forces a reboot because it guarantees that the updates in the offline updater occur on a pristinely-booted system, meaning no live changes can be in play.
It’s an overly-paranoid solution, granted. Those of us who know how it all fits together can still use DNF and systemctl restart when we know it will work; GNOME Software doesn’t prevent or get in the way of that. However, the goal of GNOME Software is to work all the time, no matter the technical acumen of the person using it. So it made some tradeoffs in favor of reliability rather than uptime.
I don’t think this was ever the case. What will load the new kernel? The old kernel? But then that means the old kernel must still be running, so it needs to replace itself but not affect other programs that are running… I hope you see where this is going. It is a very very hard problem to solve
Although that kind of implementation is in fact posible with newer kernel versions it is not really straight-forward to achieve and requires special bits compiled in the kernel. So most simple answer is “just reboot”
For a bit more background information, as far as i know, the decision to apply updates only upon reboot was made by Gnome Project’s developers some time ago, about a year or two. As Fedora tends to not to stray very far from upstream projects’ decisions, this is the default behavior in Gnome in Fedora too.
The reasoning was exactly what you guys provided in previous posts: system stability, especially for newer users. One additional argument presented was that applying updates to system that is under (heavy?) use can lead to some files being unable to be updated/replaced – let’s say if some other process uses the file in question – which will leave the system in a bad state.
I don’t have links ready, but it should be easy to find if someone interested. There were some backlash from the users (not only Fedora’s ones) at the time.
I think (I’m not sure) that KDE’s default GUI package manager doesn’t enforce reboots.
I second this strongly, I’ve been using this for several releases now.
Whew! It’s been a long time since I made this post but boy has discourse made sure to email me updates regardless. I’m gonna go change that setting right now. I made this post back when I was still a linux newbie and uncomfortable with the command line. Now that I have adjusted to it, I have no problem running updates via dnf and then restarting services, or the entire computer, as I now understand the importance of the reboot and the reasoning behind it.
Suggestion for the mods: Discourse has the option to close topics after a set amount of time. On the other forum I’m on, also a discourse forum, we have that enabled to prevent old topics from coming back from the dead haha. In any case, this is a non-issue now, I think its fine to lock the thread. I do appreciate the activity and helpful comments even almost a year later though!
Yes. We had enabled this feature… probably after this post. Topics posted and marked as solved before the change weren’t locked automatically by Discourse.
I’m going to close this topic now, as you suggest.