Hello everyone! I am using the Cinnamon Spin of Fedora 30 and I recently replaced DnfDragora with the GNOME Software center. I’ve run into something unusual, GNOME software wants me to restart to install updates. I know for a fact that a reboot is not required to install updates in any Linux Distro. I can install updates via “sudo dnf upgrade” without restarting. I’m just curious if anyone else has experienced this, and if so, how did you correct the problem? Or is this just a quirk of GNOME Software? Thanks for your help!
In fact reboot is required in some scenarios. For example, some library your init system depends on is updated. In order to load newer version of that library easiest way is to reboot. Same goes for kernel.
Though, I have noticed as well that Gnome software is reboot happy and prompts for reboot quite often, even when service restart would resolve a need to reboot, but I guess that’s the limitation of the GUI; how to present package upgrades and need to restart some specific service.
Saying restart service would confuse many, mainly new or unexperienced users.
For those wanting to look under the hood, you can always open up a terminal and issue
needs-restarting
Which would show you which processes need to be restarted.
Bear in mind above said, if process requiring restart is init or something like that, it is just easier to reboot.
2 Likes
Is that specific to Gnome Software? sudo dnf update restarts services without prompting the user, so it’s unclear to me why any updater would be limited from doing so as well.
Awesome! I had to install dnf-utils first which was not already installed. As a side note, searching with dnf provides needs-restarting is an example of why I like dnf.
I see you know your way around quite well 
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).
From what I’ve seen, there is no decision-making process. Flatpaks are allowed to update themselves online, everything else has to upgrade offline.
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… 
).
1 Like
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.
12 Likes
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
This is what the plugin suggested:
You should restart:
* Some applications using:
dropbox stop; dropbox start
killall -3 gnome-shell
pulseaudio --kill; pulseaudio --start
sudo systemctl restart ModemManager
sudo systemctl restart NetworkManager
sudo systemctl restart NetworkManager
sudo systemctl restart abrt-journal-core
sudo systemctl restart abrt-oops
sudo systemctl restart abrt-xorg
sudo systemctl restart abrtd
sudo systemctl restart accounts-daemon
sudo systemctl restart alsa-state
sudo systemctl restart atd
sudo systemctl restart auditd
sudo systemctl restart bolt
sudo systemctl restart colord
sudo systemctl restart crond
sudo systemctl restart cups
sudo systemctl restart dbus-:1.8-org.freedesktop.problems@0
sudo systemctl restart dbus-broker
sudo systemctl restart dbus-broker
sudo systemctl restart docker
sudo systemctl restart firewalld
sudo systemctl restart fwupd
sudo systemctl restart gdm
sudo systemctl restart geoclue
sudo systemctl restart gssproxy
sudo systemctl restart libvirtd
sudo systemctl restart polkit
sudo systemctl restart rngd
sudo systemctl restart smartd
sudo systemctl restart sssd
sudo systemctl restart sssd
sudo systemctl restart sssd
sudo systemctl restart sssd-kcm
sudo systemctl restart systemd-journald
sudo systemctl restart systemd-logind
sudo systemctl restart systemd-machined
sudo systemctl restart systemd-resolved
sudo systemctl restart systemd-udevd
sudo systemctl restart tpm2-abrmd
sudo systemctl restart udisks2
sudo systemctl restart upower
sudo systemctl restart wpa_supplicant
tracker daemon --terminate=store; tracker daemon --start store
* These applications manually:
(sd-pam)
QtWebEngineProcess ...
QtWebEngineProcess --type=zygote --webengine-schemes=qrc:sLV --lang=en-GB
Xwayland
abrt-applet
at-spi2-registryd
deja-dup-monitor
dnf
evolution-addressbook-factory
evolution-alarm-notify
evolution-calendar-factory
evolution-source-registry
flatpak-session-helper
gdm-session-wor
gnome-calendar
gnome-pomodoro
gnome-session-binary
gnome-shell-calendar-server
gnome-software
gnome-terminal-server
goa-daemon
goa-identity-service
gsd-a11y-settings
gsd-clipboard
gsd-color
gsd-datetime
gsd-disk-utility-notify
gsd-housekeeping
gsd-keyboard
gsd-media-keys
gsd-mouse
gsd-power
gsd-print-notifications
gsd-rfkill
gsd-screensaver-proxy
gsd-sharing
gsd-smartcard
gsd-sound
gsd-wacom
gsd-xsettings
gvfs-goa-volume-monitor
gvfsd-dnssd
gvfsd-http
gvfsd-network
ibus-daemon
ibus-dconf
ibus-engine-simple
ibus-extension-gtk3
ibus-portal
parcellite
qutebrowser
ssh-agent
sudo
tracker-miner-fs
xdg-desktop-portal
xdg-desktop-portal-gtk
xdg-document-portal
xdg-permission-store
Additionally to those process above, there are:
- 12 processes requiring restart of your session (i.e. Logging out & Logging in again)
- 4 processes requiring reboot
For more information run:
sudo tracer -iat 1557937269.9950528
3 Likes
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.
1 Like
I learn something new each day. I legit thought you can always update without restart. Thank you for the clarification!
1 Like
Not exactly; GNOME Software only stages the updates until the next boot. If you don’t reboot, you don’t pick up the changes.
4 Likes
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.
2 Likes
And I always thought that e.g. kernel update doesn’t require reboot. If PC goes idle, rewake will load new kernel version… So now?
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”
2 Likes
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.
1 Like
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.
I tried this by got python3-dnf-plugin-tracer instead. I m guessing the package has been renamed.
There’s always the “old school” option of running
# lsof | grep DEL | grep /usr
to see what has been impacted by an update and needs restarting.
1 Like