https://bugs.kde.org/show_bug.cgi?id=522307
Bug ID: 522307
Summary: kwalletd6 spins in infinite ReadAlias("default") D-Bus
loop after screen unlock from suspend, causing
constant ksecretd CPU usage
Classification: Frameworks and Libraries
Product: frameworks-kwallet
Version First 6.27.0
Reported In:
Platform: openSUSE
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Created attachment 193806
--> https://bugs.kde.org/attachment.cgi?id=193806&action=edit
dbus-monitor capture showing kwalletd6 stuck in infinite ReadAlias("default")
loop after resume+unlock
SUMMARY
After resuming from suspend and unlocking the screen, kwalletd6 gets
stuck calling org.freedesktop.Secret.Service.ReadAlias("default") on
ksecretd in a tight infinite loop (roughly every 7ms, never stopping),
causing constant ~4-5% CPU usage on ksecretd indefinitely. A full
reboot fixes it every time, but the issue reliably returns after the
next suspend/resume + screen unlock cycle. Manually killing kwalletd6
(`killall kwalletd6`) also immediately stops the CPU usage.
SOFTWARE VERSIONS
OS: openSUSE Tumbleweed (snapshot 20260625)
kwalletd6: 6.27.0-1.1
kf6-kwallet: 6.27.0-1.1
libKF6Wallet6 / libKF6WalletBackend6: 6.27.0-1.1
pam_kwallet6: 6.7.1-1.1
Desktop: KDE Plasma, KWallet/Secret Service backend = ksecretd
STEPS TO REPRODUCE
1. Log in normally (full PAM login flow completes, ksecretd/kwalletd6
start and behave normally at this point).
2. Suspend the machine (e.g. via lid close / sleep button).
3. Resume, and unlock the screen with the regular login password via
kscreenlocker_greet.
4. Observe ksecretd CPU usage in a process monitor (e.g. btop) — it
stays elevated (~4-5%) indefinitely instead of returning to idle.
OBSERVED RESULT
ksecretd shows sustained CPU usage after every resume+unlock cycle.
Confirmed via dbus-monitor that the cause is kwalletd6 (D-Bus unique
name resolved via `busctl --user status`) calling ReadAlias("default")
on org.kde.secretservicecompat in a continuous loop with ~7ms between
calls, never terminating:
method call sender=:1.55 -> destination=org.kde.secretservicecompat
path=/org/freedesktop/secrets interface=org.freedesktop.Secret.Service
member=ReadAlias
string "default"
[... repeats continuously, ~7ms apart, indefinitely ...]
Manually calling the same method returns a valid, correct answer
immediately:
$ busctl --user call org.kde.secretservicecompat \
/org/freedesktop/secrets org.freedesktop.Secret.Service \
ReadAlias s "default"
o "/org/freedesktop/secrets/collection/kdewallet"
So the loop is not caused by a missing/broken alias — kwalletd6 keeps
polling even though it would get a correct, successful answer
immediately if it just asked once.
EXPECTED RESULT
kwalletd6 should resolve the alias once (or react to a proper D-Bus
signal) and stop polling, as happens after a normal full login/reboot.
ADDITIONAL OBSERVATIONS
- journalctl logs show, at the unlock that triggers the issue:
kscreenlocker_greet[...]: pam_kwallet5(kde:auth): pam_kwallet5:
pam_sm_authenticate
kscreenlocker_greet[...]: pam_kwallet5(kde:auth): pam_kwallet5: we were
already executed
kscreenlocker_greet[...]: pam_kwallet5(kde:setcred): pam_kwallet5:
pam_sm_setcred
This suggests the screen-unlock PAM flow is a shortened version of
the full login PAM flow (the auth stage is skipped because kwallet
is already unlocked), and something kwalletd6 normally expects from
that auth stage during a full login never arrives in this shortened
flow, causing it to poll indefinitely instead of giving up/timing out.
- A full system reboot reliably "fixes" the issue every time (full PAM
login flow completes normally), but it reappears after the very next
suspend/resume + unlock cycle.
- `~/.local/share/kwalletd/kdewallet_attributes.json` stays at a stable
size (~3.9KB, 12 entries) — this is *not* an attribute-growth bug,
purely a D-Bus polling/CPU issue, no disk I/O involved (confirmed via
strace showing no further file writes during the loop, only D-Bus
traffic).
- /usr/lib/pam.d/kde (used for kscreenlocker, "kde" PAM service) does
not reference pam_fprintd — fingerprint auth is unrelated, this
reproduces purely via password-based screen unlock.
I searched bugs.kde.org and was unable to find an existing report
describing this specific loop. Happy to provide further strace/gdb
output from the running kwalletd6 process if useful for debugging.
--
You are receiving this mail because:
You are watching all bug changes.
