https://bugs.kde.org/show_bug.cgi?id=502960
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|openSUSE |Debian stable CC| |[email protected] --- Comment #34 from [email protected] --- Can confirm and narrow down the root cause. This isn't intermittent or load-related — it's deterministic and tied specifically to having an active login session for a system-class account (UID < 1000, e.g. root) open at the same time as a normal user session. Reproduced on Plasma 6.3.6 (Wayland), systemd ~256-ish range, by simply running su to root in a terminal while logged in normally as a regular user. This causes logind/pam_systemd to spin up a separate per-user systemd manager for UID 0 ([email protected]), exactly as it would for any other login. That manager has drkonqi-coredump-launcher.socket enabled via the default preset, same as any user's instance, and attempts to start it. The unit's ConditionUser=!@system then fails — not transiently, but permanently, since UID 0 is unconditionally classified as belonging to systemd's @system user group. Combined with UpheldBy=sockets.target (Upholds=, added in systemd 249), which per the systemd.unit(5) docs continuously restarts any unit found "inactive or failed" with no backoff beyond systemd's own internal start-rate-limiter, this produces an infinite retry loop: condition check fails → skipped → still considered "should be active" by sockets.target → retried roughly every 10–11 seconds → hits systemd's internal trigger-limit → "tried too often recently, will retry later" → repeats indefinitely for as long as the root (or other system-UID) session stays open. Confirmed via coredumpctl list that no actual crash/coredump correlates with any of the timestamps where this fires — it is entirely unrelated to real crash activity, just the Upholds mechanism perpetually fighting a condition that can never pass for that UID class. Workaround in the meantime is systemctl --user mask drkonqi-coredump-launcher.socket run from within the affected UID's session (e.g. as root, from the su shell itself). Possible upstream fixes: either drop Upholds= in favor of Wants= (loses the auto-recovery this was added for, but stops the perpetual retry against an unwinnable condition), or exclude system-class UIDs from the preset/Install entirely so the unit is never enabled for @system accounts in the first place, or have the launcher's own packaging logic check ConditionUser once at install time rather than relying on systemd to keep re-evaluating and retrying it at runtime. -- You are receiving this mail because: You are watching all bug changes.
