Is it a known issue? Any known workaround? I suspect the recent kernel update but I’m not sure.
I’m using Fedora 42 with Cinnamon DE. Don’t think Cinnamon has any connection to this issue, but just FYI.
One time it finished shutdown after very very long wait. After that it’s stuck forever during shutdowns or I just loose my patience and hard-rebooting it before that very long time period is elapsed.
When reporting a problem, please provide enough detail to allow others to reproduce the issue. I suggest posting (as pre-formatted text using the </> button from the top line of the text entry panel) hardware details from running inxi -Fzxx in a terminal. Then run journalctl --no-hostname -b -1 scroll down to the and use timestamps to see if there are errors associated with the long delay (see man journalctl for explanations of the options). Here I see:
Apr 23 09:58:02 systemd-shutdown[1]: Syncing filesystems and block devices.
Apr 23 09:58:02 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Apr 23 09:58:02 systemd-journald[614]: Received SIGTERM from PID 1 (systemd-shutdow).
Apr 23 09:58:02 systemd-journald[614]: Journal stopped
If you are using external devices (storage, RF dongles, etc), does the problem occur when non-essential devices are removed?
I waited a few minutes longer befor doing a long press on the power button, this all I have in the logs, from the time I’ve initiated the reboot using Cinnamon DE:
Also one time I tried doing reboot by running sudo reboot and it rebooted my system very quickly.
I tried another time and this time I waited longer. I see the following time gap in the logs of this reboot process:
Apr 26 01:57:33 systemd[1]: firewalld.service: Deactivated successfully.
Apr 26 01:57:33 systemd[1]: Stopped firewalld.service - firewalld - dynamic firewall daemon.
Apr 26 01:57:33 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=firewalld comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 26 01:57:33 systemd[1]: Stopping polkit.service - Authorization Manager...
Apr 26 01:57:33 systemd[1]: polkit.service: Deactivated successfully.
Apr 26 01:57:33 systemd[1]: Stopped polkit.service - Authorization Manager.
Apr 26 01:57:33 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=polkit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 26 01:57:33 audit: BPF prog-id=70 op=UNLOAD
Apr 26 01:57:33 audit: BPF prog-id=60 op=UNLOAD
Apr 26 02:02:03 dnf5daemon-server[2401]: 2025-04-25T23:02:03+0000 [2401] DEBUG Metadata removal from repository cache in path "/var/cache/dnf5daemon-server/terra-2cbdb71aadff9295" complete. Removed 5 files, 1 directories (total of 731040 bytes). 0 errors
Apr 26 02:02:03 dnf5daemon-server[2401]: 2025-04-25T23:02:03+0000 [2401] DEBUG Solv files removal from repository cache in path "/var/cache/dnf5daemon-server/terra-2cbdb71aadff9295" complete. Removed 2 files, 1 directories (total of 803588 bytes). 0 errors
Apr 26 02:02:03 dnf5daemon-server[2401]: 2025-04-25T23:02:03+0000 [2401] DEBUG Downloading metadata for repo "terra"
Apr 26 02:02:03 dnf5daemon-server[2401]: 2025-04-25T23:02:03+0000 [2401] TRACE countme: no event for repo "terra": window already counted
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] WARNING Error loading repo "terra" (skipping due to "skip_if_unavailable=true"):
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] WARNING std::exception
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "@System" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "copr:copr.fedorainfracloud.org:dsommers:openvpn3" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "updates" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "fedora" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "@System" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "fedora-cisco-openh264" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "rpmfusion-free" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "rpmfusion-free-updates" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "rpmfusion-nonfree-updates" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "rpmfusion-nonfree" with added file provides
Apr 26 02:02:05 dnf5daemon-server[2401]: 2025-04-25T23:02:05+0000 [2401] DEBUG Rewriting repo "code" with added file provides
Apr 26 02:02:05 systemd[1]: dnf5daemon-server.service: Deactivated successfully.
Apr 26 02:02:05 systemd[1]: Stopped dnf5daemon-server.service - DNF daemon.
Apr 26 02:02:05 systemd[1]: dnf5daemon-server.service: Consumed 1.041s CPU time, 323.4M memory peak.
Apr 26 02:02:05 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf5daemon-server comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 26 02:02:05 systemd[1]: Stopped target basic.target - Basic System.
The time gap is between Apr 26 01:57:33 and Apr 26 02:02:03 when dnf5daemon-server started to log something related repositories sync during the reboot.
Could the following be also related to this issue fix of which was adopted by the dnfdragora package maintainer?
Will try restarting Fedora when dnfdragora-updater is not running.
Ok, I’ve tried to restart Fedora with Cinnamon DE several times when dnfdragora-updater is not running (I disabled it to be ran on startup) the original issue never happened.
So the root of this issue seems to be a bug in the dnf5daemon-server or in some other part of the DNF5 infrastructure that seems to be not interruptible (when it checks for new upgrades) during a graceful system shutdown. And the right fix should be just making it always interruptible.
Before the 2360093 issue was fixed the dnfdragora-updater was broken in Fedora 42 and was unable to initiate any periodic dnf check-upgrade. And before Fedora 42 dnfdragora worked with DNF4 and not with DNF5. Maybe now dnfdragora-updater does those checks too often but I think it’s not guilty in the current restart/shutdown stuck issue.
Just submitted the following bug report in the RedHat Bugzilla:
As a workaround I disabled running dnfdragora-updater in the Startup Applications, temporarily.