https://bugs.kde.org/show_bug.cgi?id=522615
Tomasz C. <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #8 from Tomasz C. <[email protected]> --- Trigger found: name conflict over org.freedesktop.secrets with gnome-keyring I hit this bug on Arch (Plasma 6.7.4, kwallet 6.28.0, libsecret 0.21.7) with gnome-keyring 1:50.0 installed alongside. The trigger turned out to be gnome-keyring-daemon owning the org.freedesktop.secrets D-Bus name. Once it was out of the picture, the leak stopped and has not returned. THE CORE ISSUE gnome-keyring returns a Prompt object path but never creates the object: Unlock -> object path "/org/freedesktop/secrets/prompt/u1" Prompt.Prompt on that path: Error org.freedesktop.DBus.Error.UnknownMethod: No such object path Introspect /org/freedesktop/secrets/prompt: <node> <- empty The counter increments on each attempt (u1, u2, u3), so every request announces a new prompt without ever registering it on the bus. A spec-compliant client then waits forever for Completed -- which is exactly the GTask secret_service_real_prompt_async (...) finalized without ever returning received unexpected result type ao from Completed signal instead of expected o pair seen on the kwalletd6 side. Starting gcr-prompter by hand makes it register org.gnome.keyring.SystemPrompter and PrivatePrompter correctly and changes nothing, so the fault is in the daemon itself, not in prompter availability. WHY THIS ONLY SURFACED NOW On this system gnome-keyring has been socket-activated since 2024 and caused no trouble for years. Symptoms appeared only after KWallet moved to the kwalletd6 + ksecretd split, where kwalletd6 itself acts as a Secret Service client. That suggests gnome-keyring is not the cause here but merely exposes the new code path -- and that a guard on the kwalletd6 side is the right place to fix it. RESOLUTION Either mask the daemon: systemctl --user mask --now gnome-keyring-daemon.service \ gnome-keyring-daemon.socket or uninstall gnome-keyring entirely, which is what I ended up doing. Removal is straightforward where dependents require the virtual org.freedesktop.secrets provider rather than gnome-keyring by name, since kwallet provides it as well. Note that ~/.local/share/keyrings/ survives removal but nothing is left that can read it, so migrate any secrets you still need first. Either way ksecretd takes over org.freedesktop.secrets. kwalletd6 went from ~900 MB/min growth at 95% CPU to a steady 57 MB at essentially zero CPU, and D-Bus traffic dropped from ~50,000 to ~10 messages per 4 seconds. WHAT DID NOT HELP apiEnabled=false in kwalletrc, and unloading the kded networkmanagement module. The latter came back after a plasma-kded6 restart and the loop still did not reappear with gnome-keyring gone -- to me the strongest indication that the name conflict is the culprit rather than the module. QUICK CHECK FOR OTHERS dbus-send --session --print-reply --dest=org.freedesktop.DBus \ /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID \ string:org.freedesktop.secrets If the returned PID belongs to gnome-keyring-daemon instead of ksecretd, this is likely the same situation. CAVEAT This is a single environment and it need not explain every occurrence; reporters on openSUSE or Fedora may not have gnome-keyring installed at all. Regardless, a guard on the kwalletd6 side seems worth considering -- a timeout or a retry limit while waiting for Completed -- so that a broken Secret Service implementation on the other end cannot cause unbounded memory growth. -- You are receiving this mail because: You are watching all bug changes.
