https://bugs.kde.org/show_bug.cgi?id=522307
zosima <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from zosima <[email protected]> --- Confirming this on a second distro, with three additional data points: the implicated pam_kwallet6 version matches, suspend/resume is NOT required to trigger it, and downgrading pam_kwallet6 (your bisect) eliminates the problem. I have posted full forensics in bug 522615, which appears to be the memory-leak face of this same loop — in my case the end state was far more severe than sustained CPU: kwalletd6 leaked to ~53 GB RSS at ~1 GB/min and was OOM-killed by the kernel. SOFTWARE VERSIONS OS: Fedora 44 (KDE spin), kernel 7.0.14-201.fc44.x86_64 Plasma: 6.7.1 (Wayland) kf6-kwallet / kwalletd6: 6.27.0-1.fc44 pam-kwallet (pam_kwallet6): 6.7.1-1.fc44 <-- the version your snapshot bisect implicates Secret Service backend: ksecretd OBSERVED - Fresh boot + normal PAM login. journalctl confirms zero suspend/resume events in the boot ("PM: suspend" count = 0) — so the trigger here was the login handoff itself, not the screenlocker path. - ksecretd (started via pam: /usr/bin/ksecretd --pam-login 13 14) began consuming sustained CPU from login: ~32% of a core, 21m57s CPU time over 68 minutes of wall clock. - kwalletd6 was D-Bus-activated 8 minutes after login and its RSS grew continuously until the kernel OOM-killed it at ~55 GB anon RSS (details in bug 522615). - The instant kwalletd6 died, ksecretd CPU dropped to zero (measured 0 scheduler ticks over 5 s) — consistent with your dbus-monitor finding that kwalletd6 drives the loop, and with "killall kwalletd6 stops it". - Both daemons logged portal registration failures at startup: kwalletd6: Failed to register with host portal QDBusError(..., "Could not register app ID: App info not found for 'org.kde.kwalletd'") ksecretd: "... Connection already associated with an application ID" - The respawned kwalletd6 immediately logged Secret Service *client* errors: received unexpected result type ao from Completed signal instead of expected o GTask secret_service_real_prompt_async (...) finalized without ever returning i.e. kwalletd6 acting as a libsecret client of ksecretd, matching the suspected SecretServiceClient::defaultCollection() path in comment 4. CONFIRMED: DOWNGRADE FIXES IT Fedora never shipped pam_kwallet6 6.7.0, so I downgraded to 6.6.4-1.fc44 (pre-regression). After reboot: wallet unlocks normally via PAM, ksecretd consumes zero CPU (0 scheduler ticks over 10 s, 0:00 accumulated after several minutes — previously ~32% from the first minute), kwalletd6 RSS flat at ~60 MB. This independently confirms your bisect on a second distribution, and extends the trigger from "suspend/resume + unlock" to the initial PAM login handoff as well. -- You are receiving this mail because: You are watching all bug changes.
