I have experienced the same issue after recently upgrading to Kubuntu 25.04.

I managed to find out what I think is the problem.

It turns out the drkonqi-coredump-launcher.socket unit is in the global user space and runs for the root user which is not allowed by the user condition (ConditionUser=!@system). This is why the logs get flooded.

Run as root:

> systemctl --user status drkonqi-coredump-launcher.socket

The systemd global user space is located in the etc directory /etc/systemd/user

I am not sure if the drkonqi-coredump-launcher.socket unit should be in the global user space or it is the incorrect target. Maybe a different target would prevent it starting as the root user i.e. a graphical target instead of the socket target.

The fix is to disable the global unit for drkonqi-coredump-launcher.socket

Run as root:

> systemctl --global disable drkonqi-coredump-launcher.socket

It maybe required to then enable the drkonqi-coredump-launcher.socket in the local user space.

Run as user:

> systemctl --user status drkonqi-coredump-launcher.socket

If disabled run:

> systemctl --user enable drkonqi-coredump-launcher.socket

To check all drkonqi units run this command:

> systemctl --user status drkonqi*

@drkonqi maintainers is the systemd configuration something provided in the software package or is it related to the distribution package?

 Mark Ferguson's fix seems to work for me. Kudos.

>> @drkonqi maintainers is the systemd configuration something provided in the software package or is it related to the distribution package?

I strongly second getting an answer to this question. @drkonqi maintainers PLS.

Hi - for what it's worth, I've seen this message occasionally on my Fedora KDE 42 device, but it's not repeating multiple times in a row, and definitely not to this extent.

I wonder if what you're seeing involves some combination of distribution configuration choices, and this upstream change to fix a different bug: https://invent.kde.org/plasma/drkonqi/-/merge_requests/312

I had the multiple  message (16) every about 10 seconds. 
Decide to remove the package to silence the message. On tumbleweed 20250417 (latest) using KDE X11.

[1] erase drkonqi6-6.3.4-1.1.x86_64: success

[2] rebooted, no messages.

Installed it back.
[3] install drkonqi6-6.3.4-1.1.x86_64: success
[4] rebooted

It looks like it is proper now, no extra messages.

User 1000 Active
systemctl --user status drkonqi-coredump-launcher.socket

● drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash
     Loaded: loaded (/usr/lib/systemd/user/drkonqi-coredump-launcher.socket; disabled; preset: enabled)
     Active: active (listening) since Sat 2025-04-19 09:36:25 CDT; 3h 27min ago
 Invocation: e42036a0ab414a759d7b1d7bf6315eb6
     Listen: /run/user/1000/drkonqi-coredump-launcher (SequentialPacket)
   Accepted: 0; Connected: 0;
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/drkonqi-coredump-launcher.socket

ROOT USER (inactive dead)
○ drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash
     Loaded: loaded (/usr/lib/systemd/user/drkonqi-coredump-launcher.socket; disabled; preset: enabled)
     Active: inactive (dead)
  Condition: start condition unmet at Sat 2025-04-19 09:37:11 CDT; 3h 47min ago
             └─ ConditionUser=!@system was not met
     Listen: /run/user/0/drkonqi-coredump-launcher (SequentialPacket)
   Accepted: 0; Connected: 0;

Apr 19 09:37:11 plato systemd[17365]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).

Only that one initialization message in log (09:37).

It seems like an update on about April 8 started this and did not update correctly ?!

Something interesting I just noticed.

I moved to Kubuntu 25.04 on 2 machines.

Laptop via the upgrade path from 24.10 and Desktop clean install from iso (The upgrade had an unrecoverable package error so needed to do a clean install)

On the laptop this issue did not appear.
It was only on the Desktop with the clean install that had this issue.

From what I understand on the 24.10 to 25.04 upgrade path the systemd global user drkonqi links did not get recreated , so the existing ones where left in place.

Specifically for drkonqi-coredump-launcher.socket unit there is this difference:

Laptop (upgrade):
> /etc/systemd/user/sockets.target.wants/drkonqi-coredump-launcher.socket

Desktop (clean install):
> /etc/systemd/user/sockets.target.wants/drkonqi-coredump-launcher.socket
> /etc/systemd/user/sockets.target.upholds/drkonqi-coredump-launcher.socket

The drkonqi-coredump-launcher.socket unit includes an UpheldBy property
> UpheldBy=sockets.target

UpheldBy is the reverse relationship to Upholds and this will cause the unit to constantly restart on failure.

And the ConditionUser=!@system also on the unit causes a failure when run as the root user.

I did a quick test on the laptop by enabling the drkonqi-coredump-launcher.socket in my user space and the extra upholds drkonqi-coredump-launcher.socket link was created.
> ~/.config/systemd/user/sockets.target.upholds/drkonqi-coredump-launcher.socket

Which seems to confirm the systemd global user drkonqi links did not get recreated on the upgrade path.

Changing to the root user on the laptop still produces the unmet condition in the log however this only happens once.

Seems there is an edge case in systemd where defining UpheldBy and a run Condition go contrary to each other.

Is there another target that can be used that would not apply to the root user for the drkonqi-coredump-launcher.socket unit?

I was also having this issue and I am on openSUSE Tumbleweed 20250424.  I was getting 10's of these every second, my log was spammed hard for days it seems (I don't look often).

I followed Craig Anderson's fix for Tumbleweed and uninstalled it using `zypper rm drkonqi6` - then I rebooted and did a `zypper in drkonqi6` and rebooted again.  All seems well and can confirm it's running as UID 1000 now.  I'd say this is likely a distro issue not a KDE issue.

> I'd say this is likely a distro issue not a KDE issue.

Given that Tumbleweed and Kubuntu are both affected and they have completely unrelated packaging, it's at least not distro specific.

The message should only be printed once for each attempt the .socket unit is started. If that happens in a loop, something triggers systemd reloads or reexecs. Please try "systemctl --user log-level debug" to get some more detailed logs for why this is triggered.

Looking closer at the drkonqi-coredump-launcher.socket systemd unit source points to the potential problem  

 https://github.com/KDE/drkonqi/blame/master/src/coredump/launcher/drkonqi-coredump-launcher.socket

2 months ago the condition check got added to the file

> ConditionUser=!@system

This is the last section in the file

> # Prevents trigger-limit-hit failure state by restarting the unit (systemd 250[?])
> UpheldBy=sockets.target

Having the unit defined in the systemd global user space means it can be enabled automatically for any logged in user.

The condition check on the system users seems an improvement however in combination with the UpheldBy option this causes a continuous failure when the unit is enable for the root user (sudo to root is enough to trigger this action)

I am not that familiar with systemd to know if there is another way to configure the unit so it would not run as the root user but also allow the restart functionality for other users. Hopefully this is a common scenario otherwise it probably should be raised as a feature request to the systemd project.

Btw, the bug is also triggered when SSH-ing into the PC.

(In reply to Chandradeep Dey from comment #9)
> Btw, the bug is also triggered when SSH-ing into the PC.

Sorry, it was the sddm user, not SSH. I only saw it on the SSH PC because that one stays on the sddm screen for long periods of time.

Not sure why the status of this is NEEDSINFO, but I see this in syslog too on current Debian testing (almost trixie), with drkonqi 6.3.4.

(In reply to Luigi Toscano from comment #11)
> Not sure why the status of this is NEEDSINFO, but I see this in syslog too
> on current Debian testing (almost trixie), with drkonqi 6.3.4.

Because of

> Please try "systemctl --user log-level debug" to get some more detailed logs for why this is triggered.

Meanwhile I saw that myself though and there is nothing logged. Systemd really just retries it itself every 10s.

This is something to report upstream and maybe disable UpheldBy in the meantime.

I did the log level debug thing and it does print more, but nothing useful...  It just goes about listing the steps it's doing, one unit file after another.  It does not print the name of anything new, sockets.target and DrKonqi.

I ran
root@mx3:~# systemctl --user log-level notice
and that stops most of the messages :)

Setting the log level as my user does nothing, only root is effected and that matches the error.  Something running as root is crashing over and over?

```
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Unit is started because upheld by active unit sockets.target.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Trying to enqueue job drkonqi-coredump-launcher.socket/start/fail
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Installed new job drkonqi-coredump-launcher.socket/start as 1248221
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Enqueued job drkonqi-coredump-launcher.socket/start as 1248221
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: ConditionUser=!@system failed.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Starting requested but condition not met. Not starting unit.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Job 1248221 drkonqi-coredump-launcher.socket/start finished, result=done
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Unit is started because upheld by active unit sockets.target.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Trying to enqueue job drkonqi-coredump-launcher.socket/start/fail
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Installed new job drkonqi-coredump-launcher.socket/start as 1248225
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Enqueued job drkonqi-coredump-launcher.socket/start as 1248225
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: ConditionUser=!@system failed.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Starting requested but condition not met. Not starting unit.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Job 1248225 drkonqi-coredump-launcher.socket/start finished, result=done
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Unit is started because upheld by active unit sockets.target.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Trying to enqueue job drkonqi-coredump-launcher.socket/start/fail
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Installed new job drkonqi-coredump-launcher.socket/start as 1248229
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Enqueued job drkonqi-coredump-launcher.socket/start as 1248229
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: ConditionUser=!@system failed.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Starting requested but condition not met. Not starting unit.
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket: Job 1248229 drkonqi-coredump-launcher.socket/start finished, result=done
May 20 22:21:58 mx3 systemd[14911]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
```

I removed that condition check from `/usr/lib/systemd/user/drkonqi-coredump-launcher.socket` and ran `# systemctl --user daemon-reload`

Now even with debug logging, I get no more messages.

My log is also spammed by these messages. No workaround is working except disabling condition check in '/usr/lib/systemd/user/drkonqi-coredump-launcher.socket' file.