Package: drkonqi
Version: 6.7.2-1
Severity: important
Tags: newcomer

Dear Maintainer,

drkonqi's coredump handling triggers an infinite crash loop when the
user session is not a Plasma session (e.g. plain GNOME/Wayland). This
is related to, but distinct from, Bug#1102945 (unmet condition check
spam) — in this case drkonqi-coredump-launcher actively crashes and
gets respawned repeatedly, causing severe system load rather than
just log spam.

* What led up to the situation:

  plasma-workspace (and its dependency drkonqi) was installed as a
  dependency of an unrelated KDE application, while the primary
  desktop session in use is GNOME on Wayland (gdm3 + gnome-shell,
  mutter 50.3). drkonqi-coredump-launcher.socket is enabled
  unconditionally for all users regardless of desktop environment
  (systemctl --user is-enabled drkonqi-coredump-launcher.socket
  reports "enabled").

* What exactly did you do (or not do) that was effective (or
  ineffective):

  An unrelated application (obs, PID 22301) segfaulted. This
  triggered systemd-coredump@.service, which in turn activated
  drkonqi-coredump-processor@.service and then
  drkonqi-coredump-launcher@<n>.service via the user socket.

  drkonqi-coredump-launcher immediately aborts with SIGABRT
  (QMessageLogger::fatal), apparently because it cannot find a
  working Qt platform plugin for the active GNOME/Wayland session
  (available plugins logged: minimal, xcb, eglfs, vnc, linuxfb,
  wayland-brcm, wayland-egl, wayland, minimalegl, offscreen,
  vkkhrdisplay — none initializes successfully in this context).

  Because drkonqi-coredump-launcher itself crashes, systemd-coredump
  captures *that* crash too, which appears to re-trigger the same
  socket-activation path. The result is a rapid loop:
  drkonqi-coredump-launcher is spawned, crashes with SIGABRT, is
  respawned, crashes again — observed at roughly one crash every
  ~500ms, producing 30+ core dumps (~850KB each) within 18 seconds
  from a single initial application crash.

* What was the outcome of this action:

  Desktop responsiveness degrades severely during the loop (D-Bus
  and disk I/O saturation from repeated core writes to
  /var/lib/systemd/coredump/), giving the impression that the GNOME
  session itself has crashed, even though gnome-shell remains
  running throughout (confirmed via journalctl timestamps showing
  continuous gnome-shell operation across the incident window).

* What outcome did you expect instead:

  drkonqi-coredump-launcher should not be socket-activated at all
  in a non-Plasma session, or should fail gracefully (log and exit
  once) rather than being respawned in a crash loop when no
  compatible Qt platform plugin / KDE session is available.