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’ll have to double check this, but it may restart services that belong to packages that have been updated, but it will not touch services that merely depend on updated packages.
By the way, dnf now has a plugin that informs the user of what software needs to be restarted:
sudo dnf install dnf-plugin-tracer
Here is an example from an update I just ran. This is the list of packages that were part of the transaction:
Installing:
kernel x86_64 5.0.14-300.fc30 updates 26 k
kernel-core x86_64 5.0.14-300.fc30 updates 25 M
kernel-modules x86_64 5.0.14-300.fc30 updates 28 M
kernel-modules-extra x86_64 5.0.14-300.fc30 updates 2.1 M
Upgrading:
flash-plugin x86_64 32.0.0.192-release adobe-linux-x86_64 8.6 M
NetworkManager-ssh x86_64 1.2.10-1.fc30 updates 66 k
NetworkManager-ssh-gnome x86_64 1.2.10-1.fc30 updates 30 k
alsa-lib x86_64 1.1.9-1.fc30 updates 403 k
alsa-plugins-pulseaudio x86_64 1.1.9-1.fc30 updates 39 k
alsa-ucm noarch 1.1.9-1.fc30 updates 49 k
alsa-utils x86_64 1.1.9-1.fc30 updates 1.0 M
container-selinux noarch 2:2.101-1.gitb0061dc.fc30 updates 47 k
dbus-broker x86_64 21-3.fc30 updates 161 k
dbus-glib x86_64 0.110-5.fc30 updates 115 k
flatpak x86_64 1.2.4-3.fc30 updates 1.1 M
flatpak-libs x86_64 1.2.4-3.fc30 updates 345 k
fuse-overlayfs x86_64 0.3-9.dev.git89bd69b.fc30 updates 50 k
gdb-headless x86_64 8.3-1.fc30 updates 3.4 M
gnome-calendar x86_64 3.32.2-1.fc30 updates 562 k
libedit x86_64 3.1-27.20190324cvs.fc30 updates 94 k
libmodulemd x86_64 2.4.0-1.fc30 updates 169 k
libmodulemd1 x86_64 1.8.10-1.fc30 updates 175 k
libnice x86_64 0.1.16-3.fc30 updates 174 k
mesa-dri-drivers x86_64 19.0.4-1.fc30 updates 14 M
mesa-filesystem x86_64 19.0.4-1.fc30 updates 18 k
mesa-khr-devel x86_64 19.0.4-1.fc30 updates 19 k
mesa-libEGL x86_64 19.0.4-1.fc30 updates 108 k
mesa-libGL x86_64 19.0.4-1.fc30 updates 149 k
mesa-libGL-devel x86_64 19.0.4-1.fc30 updates 163 k
mesa-libOpenCL x86_64 19.0.4-1.fc30 updates 319 k
mesa-libgbm x86_64 19.0.4-1.fc30 updates 38 k
mesa-libglapi x86_64 19.0.4-1.fc30 updates 36 k
mesa-libxatracker x86_64 19.0.4-1.fc30 updates 1.2 M
mesa-vulkan-drivers x86_64 19.0.4-1.fc30 updates 1.9 M
notmuch x86_64 0.28.4-1.fc30 updates 206 k
notmuch-mutt noarch 0.28.4-1.fc30 updates 16 k
notmuch-vim x86_64 0.28.4-1.fc30 updates 18 k
orc x86_64 0.4.29-2.fc30 updates 158 k
pcre2 x86_64 10.33-2.fc30 updates 248 k
pcre2-utf16 x86_64 10.33-2.fc30 updates 230 k
python3-libmodulemd x86_64 2.4.0-1.fc30 updates 22 k
python3-rpkg noarch 1.58-2.fc30 updates 162 k
qt5-qtbase x86_64 5.12.1-7.fc30 updates 3.3 M
qt5-qtbase-common noarch 5.12.1-7.fc30 updates 14 k
qt5-qtbase-gui x86_64 5.12.1-7.fc30 updates 5.7 M
qt5-qtwayland x86_64 5.12.1-3.fc30 updates 823 k
rpkg-common noarch 1.58-2.fc30 updates 27 k
unicode-ucd noarch 12.1.0-1.fc30 updates 7.1 M
wpa_supplicant x86_64 1:2.8-2.fc30 updates 1.9 M
xfsprogs x86_64 4.19.0-5.fc30 updates 1.0 M
google-chrome-stable x86_64 74.0.3729.157-1 google-chrome 56 M
Removing:
kernel x86_64 5.0.9-301.fc30 @updates-testing 0
kernel-core x86_64 5.0.9-301.fc30 @updates-testing 61 M
kernel-modules x86_64 5.0.9-301.fc30 @updates-testing 27 M
kernel-modules-extra x86_64 5.0.9-301.fc30 @updates-testing 2.1 M
Ah I see. So what you’re saying is, GNOME software is prompting me to restart to be on the safe side, even though I don’t have to if I don’t want to. Got it. Thank you.
Interesting. I am new to Fedora (1) and I was wondering if this was standard practice or because there was a firmware update among the stuff that got upgraded. Well, now I know
(1) I used Fedora at the very beginning back in 2003 with Core 1 to Core 5
Hello @runlevel0: welcome to the community! Please take a minute to go over the posts in #start-here if you’ve not had a chance to yet.
From what I know (and please correct me if this is incorrect), this is now standard practice for gnome-software, even if the update does not include a firmware update.
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.
As an alternative, you could try gpk-update-viewer (if that tool is missing: dnf install gnome-packagekit-updater). That’s another updater which won’t ask you to reboot.
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.