https://bugs.kde.org/show_bug.cgi?id=522615
Brian Cohen <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #14 from Brian Cohen <[email protected]> --- Adding a data point from openSUSE Tumbleweed that closely matches the plasma-nm/ kded6 retry loop described here — including the "new WiFi network" trigger — with two details I haven't seen in this report or in bug 522307: the loop occurred WITHOUT gnome-keyring installed, and the retried writePassword calls alternated between TWO different PSK values, which turned out to be my mistyped first attempt and the correct second attempt from the same join flow. It appears every unacknowledged save request retries forever, not just the most recent one. Environment: - openSUSE Tumbleweed, Plasma 6.7.3, kf6-kwallet / kwalletd6 6.28.0, kwalletmanager 26.04.3, pam_kwallet6 6.7.3 - gnome-keyring NOT installed; ksecretd (started via --pam-login) owns org.freedesktop.secrets and org.kde.secretservicecompat - Problem first appeared after upgrading to Plasma 6.7 / 6.7.1 I've had two episodes with different drivers: Episode 1 (2026-07-31) — kwalletd6-driven, same pattern as bug 522307: kwalletd6 called ReadAlias + CreateItem against ksecretd ~40/sec; each colliding CreateItem minted a renamed "__0_" duplicate entry in the wallet; ~175 folderUpdated signals/sec; the kwalletmanager tray applet redrew on every signal (1h28m accumulated CPU). Killing kwalletd6 stopped it; the respawned instance stayed quiet. Episode 2 (2026-08-09) — kded6-driven; killing kwalletd6 did NOT help: Trigger: I connected to a new Wi-Fi network. I mistyped the password at the first prompt, was re-prompted, entered it correctly, and connected successfully. A few minutes later the CPU storm was underway. Observed: - dbus-monitor showed kded6 (plasma-nm secret agent) calling org.kde.KWallet.writePassword ~40-55/sec (277 calls in a 5s window), every call targeting the same entry: folder: "Network Management" key: "{<connection-uuid>};802-11-wireless-security" - Successive payloads ALTERNATED between the mistyped PSK and the correct one — i.e. both save requests from the join flow were being retried indefinitely, interleaved. Each call used a different wallet handle, with `open` / `networkWallet` calls at the same rate (the agent re-opened the wallet per write). - kwalletd6 mirrored each write into ksecretd (SearchItems + CreateItem at the same rate), producing ~120-140 folderUpdated signals/sec sustained. - Resource impact: kwalletd6 RSS grew to 7.7 GB; after I killed it, the fresh instance reached 8.1 GB within ~13 minutes while the loop continued. ksecretd sat at 20-30% CPU, kwalletmanager at 60-67%, CPU package temp 93 C. What did NOT stop episode 2: - Killing kwalletd6 (fresh D-Bus-activated instance immediately re-entered the loop) - Unloading the kded networkmanagement module via org.kde.kded6.unloadModule("networkmanagement") — loadedModules confirmed it gone, but kded6 kept issuing writePassword at the same rate, so the agent object apparently survives module unload. What DID stop it, instantly: systemctl --user restart plasma-kded6.service folderUpdated went from ~1160/10s to 0/10s, and all three processes dropped to 0% CPU. (I then killed the bloated kwalletd6 once more purely to reclaim the leaked RSS; it respawned clean and stayed quiet.) Possibly relevant negative results: during episode 2 the user journal contained NONE of the log messages mentioned in this report — no GTask "finalized without ever returning", no "unexpected result type", no invalid-timer warnings, no QWizard::field messages. Combined with gnome-keyring being absent, this suggests the retry loop does not require the broken-Prompt-provider trigger — consistent with the note that there's no defensive timeout even when the Secret Service provider is functioning. One user-visible consequence others may hit: since the last retry to land wins, the wallet can end up storing the MISTYPED password even though the connection succeeded (NetworkManager still held the correct one in memory), so the next reconnect fails once and re-prompts. Happy to provide exact package versions or re-capture dbus-monitor traces (passwords redacted) if useful. -- You are receiving this mail because: You are watching all bug changes.
