## Summary When `dnf5daemon-server` is asked to load a repository configured with `repo_gpgcheck=1`, it hangs for exactly 600 seconds (10 minutes) before giving up with a generic `std::exception`. With multiple such repositories configured, the delays add up linearly, making GNOME Software's "Updates" view effectively unusable (in my case ~20 minutes of "Refreshing data" before the package list appears). The same repositories are loaded by `dnf5` CLI (`makecache --refresh`) in milliseconds. The problem is therefore specific to the `dnf5daemon-server` execution path, not to libdnf5 in general. Reproducible: Always Steps to Reproduce: 1. Install Fedora 44 (Workstation, GNOME). 2. Add a third-party repository whose `.repo` file uses `repo_gpgcheck=1`, for example: [nextdns] name=nextdns baseurl=https://repo.nextdns.io/rpm enabled=1 gpgcheck=0 repo_gpgcheck=1 gpgkey=https://repo.nextdns.io/nextdns-armored.gpg 3. Restart dnf5daemon-server to ensure a clean state: `sudo systemctl restart dnf5daemon-server` 4. Open GNOME Software and navigate to the Updates view. 5. Observe that the view stays on "Refreshing data" for ~10 minutes. Actual Results: `dnf5daemon-server` hangs for exactly 600 seconds, then emits: WARNING Error loading repo "<reponame>" (skipping due to "skip_if_unavailable=true"): WARNING std::exception The exception is uncategorized (`std::exception` rather than a specific subclass), suggesting the failure is not properly handled in the daemon's repo-loading code path. The 600-second delay is reproducible and identical across runs (measured at 602 seconds in two separate logs, to the second), which strongly suggests a hardcoded timeout rather than a network or server-side issue. Expected Results: `dnf5daemon-server` should load repositories with `repo_gpgcheck=1` in the same time it takes `dnf5` CLI to do the same — i.e. milliseconds to a few seconds, not 600 seconds per repository. Additional Information: I went through a process of elimination to isolate the cause: 1. **Network is fine.** Both the `gpgkey` URL and the `baseurl/repodata/repomd.xml` download via `curl` in well under one second: $ time curl -fsSL https://repo.nextdns.io/nextdns-armored.gpg -o /tmp/nextdns.gpg real 0m0.860s 2. **The GPG key is valid.** File is recognized as `PGP public key block` and import cleanly into the rpm keyring. 3. **Importing the key into the rpm keyring does NOT fix the problem.** After `sudo rpm --import` the daemon still hangs for 600 seconds per repository on the next refresh. 4. **`dnf5` CLI handles the exact same repository instantly.** $ time sudo dnf5 --disablerepo='' --enablerepo='nextdns' makecache --refresh (completes in well under a second) This proves that libdnf5 itself can load this repo correctly. The bug is specific to how `dnf5daemon-server` invokes the same code path. 5. **Disabling `repo_gpgcheck` confirms it as the trigger.** After: sudo dnf config-manager setopt nextdns.repo_gpgcheck=0 sudo systemctl restart dnf5daemon-server GNOME Software's Updates view loads within seconds. None of the other ~50 repositories on the system (Fedora, RPM Fusion, Google Chrome, MongoDB, NordVPN, Adoptium, etc.) cause delays — and none of them use `repo_gpgcheck=1`. The two affected repositories are the only ones with that flag set. ## Workaround Set `repo_gpgcheck=0` on the affected repositories.
does this also cause a ~5 min wait for shutdown? i have 3rd party repos (proton, brave, rpmfusion-free/nonfree, secureblue) happens 100% of the times when i run a dnf --refresh upgrade before shutting down in fedora 44 dnf5daemon-server.service/stop is the blocker
(In reply to sairithik_l from comment #1) > does this also cause a ~5 min wait for shutdown? i have 3rd party repos > (proton, brave, rpmfusion-free/nonfree, secureblue) > > happens 100% of the times when i run a dnf --refresh upgrade before shutting > down in fedora 44 > dnf5daemon-server.service/stop is the blocker Yes, it happens during shutdown or reboot for me as well. I've used the following workaround to reduce the wait time from 5 minutes to 15 seconds: Run: sudo systemctl edit dnf5daemon-server.service And add these lines: [Service] TimeoutStopSec=15s
(In reply to mauro.castaldo from comment #2) > (In reply to sairithik_l from comment #1) > > does this also cause a ~5 min wait for shutdown? i have 3rd party repos > > (proton, brave, rpmfusion-free/nonfree, secureblue) > > > > happens 100% of the times when i run a dnf --refresh upgrade before shutting > > down in fedora 44 > > dnf5daemon-server.service/stop is the blocker > > Yes, it happens during shutdown or reboot for me as well. I've used the > following workaround to reduce the wait time from 5 minutes to 15 seconds: > > Run: > sudo systemctl edit dnf5daemon-server.service > > And add these lines: > > [Service] > TimeoutStopSec=15s thanks for the solution! the issue was annoying as i frequently restart my system. is this an upstream change or a bug? not familiar with what's wrong going off of this post i'd like to change it back once the fix is in place if it's a bug
This is from dnf5, not the older dnfdaemon.
(In reply to Neal Gompa from comment #4) > This is from dnf5, not the older dnfdaemon. Thanks for clarifying. Yes, this is dnf5daemon-server specifically — the same repositories load in milliseconds via the dnf5 CLI binary, so the bug is isolated to the daemon's code path. I filed under the dnfdaemon component because dnf5daemon-server wasn't available as a separate component in Bugzilla's dropdown; feel free to reassign if there's a more specific place for it.
*** Bug 2459756 has been marked as a duplicate of this bug. ***
When loading repositories, a thread waits on a user to accept a repository key: [...] #8 0x00000000004997ee in std::condition_variable::wait_for<long int, std::ratio<60>, Session::wait_for_key_confirmation(const std::string&, sdbus::Signal&)::<lambda()> >(std::unique_lock<std::mutex> &, const std::chrono::duration<long, std::ratio<60, 1> > &, struct {...}) (this=0x7fffe4002968, __lock=..., __rtime=std::chrono::duration = { 5min }, __p=...) at /usr/include/c++/16/condition_variable:179 #9 0x0000000000497602 in Session::wait_for_key_confirmation (this=0x7fffe40027a0, key_id="8ACFA0B7", request_signal=...) at /home/test/dnf5/dnf5daemon-server/session.cpp:220 #10 0x0000000000410fa4 in dnf5daemon::KeyImportRepoCB::repokey_import (this=0x7fffe40b46c0, key_info=...) at /home/test/dnf5/dnf5daemon-server/callbacks.cpp:119 #11 0x00007ffff782f614 in libdnf5::repo::RepoPgp::import_key (this=0x7fffe430b360, fd=9, url="https://repo.nextdns.io/nextdns-armored.gpg") at /home/test/dnf5/libdnf5/repo/repo_pgp.cpp:128 #12 0x00007ffff7836dc2 in libdnf5::repo::RepoSack::Impl::update_and_load_repos (this=0x7fffe4134c70, repos=..., import_keys=true) at /home/test/dnf5/libdnf5/repo/repo_sack.cpp:574 #13 0x00007ffff78382b0 in libdnf5::repo::RepoSack::load_repos (this=0x7fffe4003098) at /home/test/dnf5/libdnf5/repo/repo_sack.cpp:700 #14 0x0000000000497ce4 in Session::read_all_repos (this=0x7fffe40027a0) at /home/test/dnf5/dnf5daemon-server/session.cpp:276 #15 0x0000000000497719 in Session::fill_sack (this=0x7fffe40027a0) at /home/test/dnf5/dnf5daemon-server/session.cpp:234 #16 0x0000000000472f64 in Repo::list (this=0x7fffe4124330, call=...) at /home/test/dnf5/dnf5daemon-server/services/repo/repo.cpp:469 [...] A timeout in the key_import_condition.wait_for() call at dnf5daemon-server/session.cpp:220 is set to 5 minutes. While there is another thread waiting on the loaded repository to be added into an array guarded by a mutex: #0 0x00007ffff7080f42 in __syscall_cancel_arch () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff7080f42 in __syscall_cancel_arch () at /lib64/libc.so.6 #1 0x00007ffff707518c in __internal_syscall_cancel () at /lib64/libc.so.6 #2 0x00007ffff70754d7 in __futex_abstimed_wait_cancelable64 () at /lib64/libc.so.6 #3 0x00007ffff7077d2c in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libc.so.6 #4 0x00007ffff7248720 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () at /lib64/libstdc++.so.6 #5 0x00007ffff7835998 in operator() (__closure=0x7fffe41a7098) at /home/test/dnf5/libdnf5/repo/repo_sack.cpp:411 #6 0x00007ffff783dd10 in std::__invoke_impl<void, libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool)::<lambda()> >(std::__invoke_other, struct {...} &&) (__f=...) at /usr/include/c++/16/bits/invoke.h:63 #7 0x00007ffff783dcd3 in std::__invoke<libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool)::<lambda()> >(struct {...} &&) (__fn=...) at /usr/include/c++/16/bits/invoke.h:98 #8 0x00007ffff783dc8e in std::thread::_Invoker<std::tuple<libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool)::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x7fffe41a7098) at /usr/include/c++/16/bits/std_thread.h:303 #9 0x00007ffff783dc62 in std::thread::_Invoker<std::tuple<libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool)::<lambda()> > >::operator()(void) (this=0x7fffe41a7098) at /usr/include/c++/16/bits/std_thread.h:310 #10 0x00007ffff783dc46 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool)::<lambda()> > > >::_M_run(void) (this=0x7fffe41a7090) at /usr/include/c++/16/bits/std_thread.h:255 #11 0x00007ffff72524f6 in execute_native_thread_routine () at /lib64/libstdc++.so.6 #12 0x00007ffff7078879 in start_thread () at /lib64/libc.so.6 #13 0x00007ffff70fd08c in __clone3 () at /lib64/libc.so.6 The confirmation should come over D-Bus, but some role plays policykit which needs to authenticate the client. We need to dig deeper. I don't know this code much. Marek could know it better.
I can reproduce it ("dnf5daemon-client repoinfo") in all Fedoras ≥ 43. I cannot reproduce it in Fedora 42. A version of dnf5daemon-server does not matter. I tried 5.4.1.0 in F42 and 5.2.18.0 in F45. DNF5 version does not matter. It must be triggered by something else.
(In reply to mauro.castaldo from comment #0) > The two affected repositories are the only ones > with that flag set. You only mentioned NextDNS. What is the other one? In bug 2459756 I hit the same issue with the Cursor repo, so that's another affected software. I could also reproduce this by running "dnf5daemon-client repoinfo", so it's not necessary to test this through gnome-software.
This will probably affect most RPM repositories on packagecloud.io, as that only supports repo_gpgpcheck.
Common issue description: https://discussion.fedoraproject.org/t/common-issue/189222
From my point of view, a non-interactive call should not invoke "repo key import request" signal, it's expected nobody is listening when it's not the interactive call. It's only half of the problem, though. Pity there's no way to detect whether anything is listening on the client side (that's impossible, of course, you'd need a function to declare "you can ask me, if needed", which would be crazy). Is there a list of the D-Bus calls which can invoke the signal? The gnome-software listens to it always during transaction. I did not add it elsewhere, because I did not expect it to happen. Having the signal listener set for each call could be done (like for the whole lifetime of the session), it only feels weird, but if it's the safest way to do this, then I'm fine to do it. Let me know your opinion, please.
I think this needs a two-sided solution. Both the client and the server should be aware of it and handle it properly. For my patch on the client side: make GNOME Software defensive so non-interactive operations, such as app startup, do not hang. For the daemon/server side: it should avoid waiting blindly unless the client call declared that interaction is allowed, or the method has an explicit interaction contract.
As mentioned in bug 2463519 comment 4 , I see this problem even though the repo GPG key seems correctly imported. So this doesn't seem to be just "user hasn't imported key" issue. Or there are multiple issues.
Upstream PR: https://github.com/rpm-software-management/dnf5/pull/2717
FEDORA-2026-2bf2cf5210 (dnf5-5.4.2.1-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2bf2cf5210
FEDORA-2026-2bf2cf5210 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2bf2cf5210` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2bf2cf5210 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2464313 has been marked as a duplicate of this bug. ***
FEDORA-2026-2bf2cf5210 (dnf5-5.4.2.1-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-7be765f087 (dnf5-5.2.18.0-4.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-7be765f087
FEDORA-2026-7be765f087 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-7be765f087` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-7be765f087 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-7be765f087 (dnf5-5.2.18.0-4.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.