https://bugs.kde.org/show_bug.cgi?id=522615
--- Comment #16 from Branislav Klocok <[email protected]> --- A second episode on the same machine today, this time caught while it was happening, which lets me answer the question about log messages properly rather than from memory. The trigger was the same as in July: joining a new network at a hotel, where the password was requested twice during the join. A few minutes later the loop was running. What it looked like, from the wallet daemon side: 16:01 5714 MOVED_TO events on kdewallet_attributes.json in that single minute 16:01:56 kwalletd6 RSS 553 MB 16:01:57 plasma-kded6 restarted, kwalletd6 killed, ~540 MB freed 16:13 kwalletd6 39 MB and falling, dbus-monitor quiet (4 lines in 5 s) That is roughly 300 MB per minute, which is the same order as the growth reported in comment #14, and on a machine with 8 GB it would have reached the OOM killer within minutes had nothing intervened. The part I could not establish before is what the journal contained. Here is every distinct message ksecretd and kwalletd6 produced in the twenty minutes around the episode, by count: 28572 got event "..." for entry "..." [file] "..." 11428 -->got CREATE signal for "..." sub_entry= 0x0 3 Structure: QMultiHash(...) / Default wallet: "..." 1 Failed to register with host portal QDBusError(...) 0 GTask / finalized without ever returning / unexpected result type Zero across the whole user journal for the surrounding half hour. So this confirms what Brian reported in comment #14, from a third configuration: the kded6 retry loop runs to the point of exhausting memory without emitting any of the prompt or GTask diagnostics this report was opened around. It also settles the caveat I raised in my previous comment - I had said I could not verify my own case because the journal had rotated, and now I can, on a fresh occurrence. One detail consistent with Brian's reading that the agent reopens the wallet on every write: the episode touched several different temporary files in the wallet directory, each accumulating hundreds of MODIFY and ATTRIB events, rather than one file being rewritten. The recovery in this case was automatic. After the July episode I put a small watchdog on a one-minute systemd user timer that restarts plasma-kded6 when kwalletd6 RSS crosses a threshold or the inotify rate on the wallet attribute file goes over 30 per minute. This was its first real trigger in 23 days, and it cut the loop 56 seconds after the threshold was crossed. I mention it because anyone hit by this repeatedly can contain the damage without waiting for a fix, and I am happy to attach the script if that is useful. No lasting damage to the wallet here: no renamed duplicate entries of the kind described in the first episode of comment #14, entry count up by the expected amount for one new network, and the connection works normally. -- You are receiving this mail because: You are watching all bug changes.
