https://bugs.kde.org/show_bug.cgi?id=522615
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #17 from [email protected] --- (In reply to Branislav Klocok from comment #16) > 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. Confirmed on OpenSUSE Tumbleweed. Happens indeed after joining a new wifi, where I get a second prompt for the password. About 20 to 30 minutes later, kwalletd6 is using 18+GB of RAM and machine crashes. -- You are receiving this mail because: You are watching all bug changes.
