https://bugs.kde.org/show_bug.cgi?id=522307
--- Comment #13 from zosima <[email protected]> --- Follow-up to my earlier comment, with a correction: I reported the pam-kwallet6 downgrade to 6.6.4 as a confirmed mitigation. It is not sufficient. The loop recurred on the same machine today with pam-kwallet-6.6.4-1.fc44 installed and versionlocked (verified at episode time via rpm -q), kf6-kwallet-6.27.0-1.fc44 unchanged. So pam_kwallet6 6.7.1 is not a necessary condition for the loop. Either the defect lives in kwalletd6/ksecretd 6.27 itself and 6.7.1 merely causes it to trigger at login, or there are two entry paths. New trigger shape (differs from both my login trigger and the original suspend/resume trigger): - Fresh boot 15:52 local. kwalletd6 was not running until 16:48:52, when it was D-Bus-activated by a client (65 min after login). - RSS growth began immediately on activation. A watchdog script I run kills kwalletd6 at >2GB RSS: it fired 6 times (16:51:25, 16:53:32, 16:55:25, 16:58:25, 17:00:25, 17:02:25), each instance reaching 2.3-4.2GB in ~2-3 min with 33-50s CPU consumed (systemd accounting). Every dbus-respawned instance re-entered the loop immediately. - During the episode, ksecretd raised a KWallet "create new wallet" dialog with the wallet name literally 'Remote peer disconnected' - a QDBusError message string propagated into the wallet-name field, presumably from a call that died when an instance was killed mid-conversation. Journal correlate: `ksecretd[4061]: Using kwallet without parent window!` at 17:02:25. - The loop terminated permanently only after that prompt flow ended (dialog cancelled). The surviving kwalletd6 instance logged at 17:04:12: `received unexpected result type ao from Completed signal instead of expected o`, `g_task_return_error: assertion 'error != NULL' failed`, and `GTask secret_service_real_prompt_async ... finalized without ever returning`. After that it stayed flat at ~60MB, and remained flat across a subsequent reboot. The correlation between an outstanding Secret Service prompt and the loop's lifetime suggests the cycle lives in kwalletd6's Secret Service client <-> ksecretd prompt path (SecretServiceClient), with a pending prompt keeping it alive - consistent with the ReadAlias("default") loop, but reachable without pam_kwallet 6.7.1. Environment: Fedora 44, Plasma (Wayland), kernel 7.0.14-201.fc44, kf6-kwallet-6.27.0-1.fc44, pam-kwallet-6.6.4-1.fc44. Full journal excerpts available on request. -- You are receiving this mail because: You are watching all bug changes.
