https://bugs.kde.org/show_bug.cgi?id=527209
Bug ID: 527209
Summary: baloo_file_extractor crash loop with no Qt platform.
makes systemd unresponsive
Classification: Frameworks and Libraries
Product: frameworks-baloo
Version First 6.31.0
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: Baloo File Daemon
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
I upgraded to plasma 6.8 and my airpods started losing audio a bit after boot.
after digging thru system logs i found that there was a crash loop in baloo
related to qt. it spammed so much into sytstemd that i could not get audio to
go thru my airpods in any way. systemd was at 100%. there might be some other
things that are affected by systemd spam, but i haven't noticed them.
I asked claude to crawl around my system and we found that it was apparently
because kde-baloo.service starts at the same time as
plasma-kwin_wayland.service and there's some QT weirdness going on.
Unfortunatelly I'm not proficient in this entire thing, but you can reach me on
telegram @m3jvn if you need to see it IRL
STEPS TO REPRODUCE
1. Upgrade to Plasma 6.8.0 (Wayland session), with Baloo file indexing enabled.
2. Boot and log in.
3. Wait for Baloo to start content indexing.
OBSERVED RESULT
I will repeat again that I'm not proficient, so I have to include what I
understand. And I apologize in advance if it doesnt make sense. so this is info
from claude + my observations:
kde-baloo.service starts at the same time as plasma-kwin_wayland.service, has
no WAYLAND_DISPLAY or DISPLAY, every baloo_file_extractor start crashes in
QGuiApplicationPrivate::createPlatformIntegration()
baloo_file restarts over and over again. i see close to 10 SIGABRTs per second.
every crash creates systemd-coredump and DrKonqi coredump jobs.
After ~20 hours of pc uptime i have 268,000 crashes!! systemd was at 100% for
one core with 2.2 GB RSS.
Anything going through systemd/D-Bus stalls including my airpods.
EXPECTED RESULT
I am not sure, wait for the display to become available? why do we even need
display for baloo?
or just don't crash as much and do hard exit at some point? maybe signal to
user that 'hay, you systemd is being bombarded because of me'
SOFTWARE/OS VERSIONS
baloo 6.31.0, kwin 6.8.0, plasma-workspace 6.8.0, qt6-base 6.12.0, systemd 262,
Arch Linux, Plasma Wayland session.
ADDITIONAL INFORMATION
i checked plasma 6.7: plasma-core.target pulled in plasma-kcminit.service and
plasma-kcminit-phase1.service, and kcminit waited for KWin. plsama 6.8 removed
these two
for now I have a workaround. in kde-baloo.service I added
Environment=QT_QPA_PLATFORM=offscreen via an override file
~/.config/systemd/user/kde-baloo.service.d/offscreen.conf. crashes stopped.
--
You are receiving this mail because:
You are watching all bug changes.
