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
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.
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
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… ).
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 188.8.131.52-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
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.
I learn something new each day. I legit thought you can always update without restart. Thank you for the clarification!
Not exactly; GNOME Software only stages the updates until the next boot. If you don’t reboot, you don’t pick up the changes.
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.
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”
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.
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.