https://bugs.kde.org/show_bug.cgi?id=520518
Bug ID: 520518
Summary: kio-fuse accumulates worker children and 2.8 GB RAM
over a long-running session (filenamesearch workers
respawn after kill)
Classification: Frameworks and Libraries
Product: kiofuse
Version First 5.1.0
Reported In:
Platform: Ubuntu
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Target Milestone: ---
DESCRIPTION
NB 1: I used Claude code to investigate high CPU usage. It pointed kioworkers,
they respawned when killed so it finally restarted the service. Once my CPU
idle, I asked it to search a filed bug to vote for. It found no matching ones
but listed those ones which may be related.
- Bug 413560 — kioworker high CPU during Trash
(https://bugs.kde.org/show_bug.cgi?id=413560)
- Bug 358833 — KIO_file 100% CPU
(https://bugs.kde.org/show_bug.cgi?id=358833)
- Bug 422142 — kioslave5 high CPU on archive open
(https://bugs.kde.org/show_bug.cgi?id=422142)
I then asked it to generate the most complete report as possible. Here is the
result.
NB 2: It is several days ago (more than a week) but I mounted some Borg backups
with Vorta. I can't remember if I ran some Dolphin searches on them
REPORT BY CLAUDE:
After ~10 days of normal desktop usage, the user-level `kio-fuse.service` ended
up consuming 23 h 25 min of CPU time and 2.8 GB peak RAM (50 MB swap peak),
with 8+ persistent `kio_filenamesearch` worker children. Killing the workers
individually (`pkill -f kio_filenamesearch`) makes systemd-user immediately
respawn them — the kio-fuse parent appears to re-request them. Only restarting
the whole service (`systemctl --user restart kio-fuse.service`) brings the
process back to a sane footprint (4.9 MB RAM, single child).
The journal right before the manual restart was looping on
`kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError` —
workers tearing down failed connections in tight succession.
STEPS TO REPRODUCE
(Best-effort — the exact trigger isn't isolated, but the runaway state
correlates with these conditions in our session.)
1. Leave a normal KDE Plasma session running for multiple days.
2. Periodically run filesystem traversals that cross under `/run/user/$UID/`
mount points (e.g. `find /` invocations from a terminal or scripted tooling).
The kio-fuse worker sockets live in that directory under names like
`kiofuseXXXXXX.N.kioworker.socket`, and traversals through them appear to
trigger fresh `kio_filenamesearch` lookups via DBus activation.
3. Each traversal leaves an additional kio_filenamesearch worker child of
kio-fuse. After dozens of such triggers, several workers stay resident and
start consuming 70–80 % CPU each.
OBSERVED RESULT
```
systemctl --user status kio-fuse
● kio-fuse.service - Fuse interface for KIO
Active: active (running) since Tue 2026-05-12 14:27:21 CEST; 1 week 3 days
ago
Tasks: 65 (limit: 18698)
Memory: 2.6G (peak: 2.8G, swap: 12.9M, swap peak: 50.2M)
CPU: 23h 21min 47.050s
CGroup: .../kio-fuse.service
├─1918562 /usr/lib/x86_64-linux-gnu/libexec/kio-fuse -f
├─3739960 .../kioworker .../kio_filenamesearch.so filenamesearch
local:/run/user/1000/kiofuseUeobpD.12.kioworker.socket
├─3740001 .../kioworker .../kio_filenamesearch.so filenamesearch
local:/run/user/1000/kiofuseGoEIwL.13.kioworker.socket
├─3740049 .../kioworker .../kio_filenamesearch.so filenamesearch
local:/run/user/1000/kiofusemBSirL.14.kioworker.socket
├─3741038 .../kioworker .../kio_filenamesearch.so filenamesearch
local:/run/user/1000/kiofuseYVNBIx.15.kioworker.socket
├─3741055 .../kioworker .../kio_filenamesearch.so filenamesearch
local:/run/user/1000/kiofuseqDduYq.16.kioworker.socket
[+3 more]
```
Total system load attributable to kio-fuse + children: ~600 % CPU sustained.
Journal snippet (last seconds before the manual restart):
```
mai 22 17:18:16 kio-fuse[3741055]: kf.kio.core.connection: Socket not connected
QLocalSocket::PeerClosedError
mai 22 17:18:16 kio-fuse[3741038]: kf.kio.core.connection: Socket not connected
QLocalSocket::PeerClosedError
mai 22 17:18:16 kio-fuse[3740001]: kf.kio.core.connection: Socket not connected
QLocalSocket::PeerClosedError
[repeats ~25 times across worker PIDs]
mai 22 17:18:17 systemd[2709]: kio-fuse.service: Consumed 23h 25min 49.569s CPU
time, 2.8G memory peak, 50.2M memory swap peak.
```
After `systemctl --user restart kio-fuse.service`, footprint dropped to:
```
Active: active (running); 3 min 34 s
Tasks: 2
Memory: 4.9M (peak: 5.9M)
CPU: 38ms
```
EXPECTED RESULT
- kio-fuse should cap or reuse `kio_filenamesearch` workers rather than letting
them accumulate one-per-invocation.
- Idle / disconnected workers should be torn down — the `PeerClosedError` lines
suggest the parent doesn't notice peers have closed and doesn't release them.
- Resident memory should stay close to the post-restart 5 MB baseline; growing
to 2.8 GB over a 10-day session indicates a leak.
SOFTWARE/OS VERSIONS
Operating System: Kubuntu 25.10
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.17.0
Qt Version: 6.9.2
Kernel Version: 6.17.0-23-generic (64-bit)
Graphics Platform: Wayland
kio-fuse package version: 5.1.0-1build1
ADDITIONAL INFO
I didn't save a core/heap dump before restarting (process was running away when
I noticed). Happy to capture one on re-occurrence — please advise on preferred
capture method (`coredumpctl`, `gdb attach + gcore`, …).
Adjacent reports with the same runaway-worker symptom but different triggers:
bug 358833 (KIO_file 100 % CPU), bug 413560 (kioworker high CPU on Trash), bug
422142 (kioslave5 high CPU on archive open). None pinpoint the kio-fuse-parent
+ filenamesearch combination observed here.
--
You are receiving this mail because:
You are watching all bug changes.
