https://bugs.kde.org/show_bug.cgi?id=524490
Bug ID: 524490
Summary: drkonqi-coredump-launcher processes never exit,
saturating the launcher socket and silently disabling
crash reporting
Classification: Applications
Product: drkonqi
Version First 6.7.4
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
On a crash recorded by coredumpctl, drkonqi-coredump-launcher is started to
show a crash notification, with a "Details" button, that on click opens the bug
report.
drkonqi-coredump-launcher stays open as long as the notification stays there.
It creates the notification with expire_timeout -1, so there is no builtin
timeout.
On GNOME, the notification never expires by itself (because GNOME notifications
are persistent), so drkonqi-coredump-launcher stays open forever.
>From my understanding, on KDE too, from MR !2178 ("Keep notifications usable in
history") on Plasma >= 6.4, notifications will stay there too without expiring.
drkonqi-coredump-launcher needs to stay open because it listens on the D-Bus
signal for "Details" being tapped on. So it can't just open the notification
and quit, it stays there to listen for the singal.
So the net effect is that for every app crash, a drkonqi-coredump-launcher
instance will run and create a notification and wait forever for someone to tap
the "Details" button or to close the app.
If there are many crashes and the notifications are never dismissed this is a
clear "leak". On my system I hit dozens of processes. This is an issue in
itself.
But then drkonqi-coredump-launcher.socket has MaxConnections=16, so after 16
crashes the socket is saturated and crash reporting stops working, until the
user dismisses the notifications again.
STEPS TO REPRODUCE
1. Run a session with notifications not auto-closing (I run gnome-shell 50.4
but I think it's applicable to KDE too)
2. Crash any process: sleep 600 & kill -SEGV %1
3. Watch drkonqi-coredump-launcher and leave the notification alone
4. Repeat 16 times
OBSERVED RESULT
The launchers never exit. On each crash one idle process is spawned, holding
12~20 MB forever.
After 16 crashes the socket is at MaxConnections=16 and further crashes are not
handled at all.
EXPECTED RESULT
The launchers should expire after a while / avoid using too much RAM on many
crashes for too long.
Also handling crashes past the 16 first should work.
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.7.4 (installed, but reproduced session is GNOME)
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 7.1.6-arch1-1 (64-bit)
Graphics Platform: Wayland
drkonqi 6.7.4-1, built with WITH_GLOBAL_NOTIFIER
ADDITIONAL INFORMATION
I investigated this a bit and originally planned on a patch, but it's a bit
tricky, not sure how to address.
The "proper fix" would likely be to create activation-based notifications, so
that the launcher just creates the notification and exits, then the process is
spawned on click, but it's significant work I think. Not sure this is supported
by the libraries the launcher uses at all.
Otherwise it's just workarounds:
- A timeout somehow, either a notification expiration time (close the
notification automatically after 24 hours?), or a RuntimeMaxSec on the launcher
just like on drkonqi-coredump-processor?
- Somehow have only 1 launcher process instead of N, who can then handle any
notification?
Up to you :P If needed if there's a clear path I can go for a patch.
I used an LLM to help identify and explore the issue but the understanding is
mine and I wrote this issue text myself.
--
You are receiving this mail because:
You are watching all bug changes.
