dnfdragora may trigger a bug in dnf5daemon-server

[rosti-il]

When the dnf5daemon-server checks for new upgrades it seems to be not interruptible by a graceful shutdown process of Fedora 42 and this may result to stuck this restart/shutdown process. The dnfdragora-updater probably checks for upgrades too often and this may trigger the above issue in dnf5daemon-server.

The real fix should be done in the dnf5daemon-server IMHO, I just wanted to inform you about this issue.

For more information please read the following:

• https://discussion.fedoraproject.org/t/after-yesterdays-update-fedora-42-is-stuck-during-shutdown-stage-of-restart/150503/1
• https://bugzilla.redhat.com/show_bug.cgi?id=2362415

As a workaround I disabled running dnfdragora-updater in the Startup Applications, temporarily.

BTW how often dnfdragora-updater checks for new upgrades? Or does it trigger the above issue in dnf5daemon-server by some other activity?

[anaselli]

BTW how often dnfdragora-updater checks for new upgrades? Or does it trigger the above issue in dnf5daemon-server by some other activity?

Well it is into the configuration file and could be changed by user into option menu. Please check if it is described as it should into Help.
Anyway the default value should be 180 minutes.

[anaselli]

Sorry but i can't understand well what the problem is, could you describe it better?
You can also open an issue to dnf5 github.
Thanks

[rosti-il]

Well it is into the configuration file and could be changed by user into option menu. Please check if it is described as it should into Help.
Anyway the default value should be 180 minutes.

I don't remember that I changed any configuration of dnfdrafora by myself but this is how it's configured in my machine. The update_interval: 48 is in minutes or in seconds?

$ cat ~/.config/dnfdragora.yaml 
settings:
  metadata:
    last_update: 2025-04-06 20:27
    update_interval: 48
  search:
    fuzzy_search: false
    newest_only: false
view:
  filter: to_update
  show: all

Sorry but i can't understand well what the problem is, could you describe it better?

According to the time gap in the logs during the too long system shutdown the dnf5daemon-server seems to be the blocker of the shutdown process:

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

And according to the next logs it was doing sync of DNF repos:

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.

And only after it finished its repos sync the shutdown process continued without further delay. This repos sync was triggered by the dnfdragor or dnfdragor-updater. Now, when dnfdragora-updater is temporarily disabled, this issue doesn't happen.

The root of this issue is that the dnf5daemon-server is not interruptable by the shutdown process in case dnf5daemon-server is doing the repos sync. That's all.

I just wanted to inform you. It doesn't look like a bug of dnfdragora but of the dnf5daemon-server.

You can also open an issue to dnf5 github.

I already submitted a bug report in the Bugzilla of RedHat/Fedora and DNF is their own project anyway. It would be too noisy to report it in two places.

[anaselli]

They should be minutes iirc.
Anyway it could be related to the way dnfdragora and dnfdragora-update work, they don't disconnect the daemon until they close. At least that is the way they worked with old daemon and i didn't change it. Maybe try a test more, exit the updater and open dnfdragora then shutdown with dnfdragora open.