https://bugs.kde.org/show_bug.cgi?id=522615
--- Comment #10 from Branislav Klocok <[email protected]> --- Since comment #8 explicitly asks whether the gnome-keyring conflict explains every occurrence, here is a data point from the openSUSE side where it does not, and the difference may help narrow down the fix. gnome-keyring is not installed at all on this system. org.freedesktop.secrets is owned by KeePassXC with its FdoSecrets integration enabled, and ksecretd does not compete for that name, because kwalletrc here contains: [org.freedesktop.secrets] apiEnabled=false That is the same setting listed under "what did not help" in comment #8, and as comment #9 explains, it leaves ksecretd with only its internal address. It matters here that it was already in place well before the leak episode I described in comment #6 - I checked that against my own session logs rather than trusting my memory, and that section of the file was not touched during the incident. Its origin is unknown to me: I did not set it, there is no system-wide kwalletrc under /etc/xdg or /usr/share/kf6, and the string appears in the ksecretd binary but not in kwalletd6. The practical consequence is that at the time of my episode nothing was contesting org.freedesktop.secrets - a third-party provider simply held it uncontested - and the loop still happened. To test hypothesis (2) from comment #9 I captured session bus traffic while driving read-only wallet calls, with kwalletd6 as :1.26, ksecretd as :1.15 and KeePassXC as :1.47: mc :1.26 -> org.kde.secretservicecompat /org/freedesktop/secrets Secret.Service.ReadAlias mc :1.26 -> org.kde.secretservicecompat /.../collection/kdewallet DBus.Properties.Get mr :1.15 -> :1.26 (replies) There was not a single message to :1.47, so kwalletd6 talks to ksecretd over the internal name exactly as intended and is not wrongly reaching for the public interface on this machine. My notes from the incident itself say the looping traffic also went to org.kde.secretservicecompat, with CreateItem, ReadAlias, Properties.GetAll and StartServiceByName at the same rate as the kded6 writePassword calls I quantified in comment #6 - the internal path again. I should be honest about how much weight that carries: the raw capture lived in /tmp and is long gone, my journal no longer reaches back that far, and my notes do not state outright that those transient connections belonged to kwalletd6, though it is by far the most plausible candidate. Please treat it as a recollection backed by written notes rather than evidence I can still produce on request. If it does hold, then the broken prompt completion can arise on the internal kwalletd6 to ksecretd path with no foreign Secret Service provider involved at all, which would make removing gnome-keyring a way to remove one trigger rather than the fix. It also argues that the guard proposed at the end of comment #8 and echoed in #9, a timeout or a retry limit while waiting for Completed, is worth having regardless of what sits on the other end. One further observation seems worth recording for other users, since KDE alongside KeePassXC is a common pairing: KeePassXC has the same gap that comment #8 describes for gnome-keyring, only more pronounced. busctl --user introspect org.freedesktop.secrets /org/freedesktop/secrets -> aliases, collection busctl --user introspect org.freedesktop.secrets /org/freedesktop/secrets/prompt -> No such object path '/org/freedesktop/secrets/prompt' There is no prompt node at all, not even the empty one reported for gnome-keyring, and no session node either, while ksecretd exposes aliases, collection and session. Anyone who lets KeePassXC hold org.freedesktop.secrets while kwalletd6 does reach for the public name should therefore expect the same hang. As for the current state here, restarting the plasma-nm secret agent with systemctl --user restart plasma-kded6.service, as described in comment #6, has held for 19 days: kwalletd6 sits at 26 MB and ksecretd at 30 MB, both at 0% CPU, the journal shows no GTask, "finalized without ever returning" or "unexpected result type" lines, and a watchdog checking RSS and the wallet inotify rate every minute has not fired once in over 3000 runs. I can capture the bus traffic properly if the loop comes back, and would welcome direction on what would be most useful to record if it does. -- You are receiving this mail because: You are watching all bug changes.
