Drkonqi-coredump-pickup.service keeps failing

cactux · April 9, 2025, 4:56pm

This systemd user service: drkonqi-coredump-pickup.service keeps failing on this installation. It is Arch if that is relevant but I think it may be something misconfigured on my end. Being a newbie to KDE Plasma, I have still a whole lot to learn about what it has under its hood.

Does anyone know where I should be looking at in order to adress this issue?

$ systemctl --user status drkonqi-coredump-pickup.service
× drkonqi-coredump-pickup.service - Consume pending crashes using DrKonqi
     Loaded: loaded (/usr/lib/systemd/user/drkonqi-coredump-pickup.service; enabled; preset: enabled)
     Active: failed (Result: timeout) since Wed 2025-04-09 18:40:03 CEST; 12min ago
   Duration: 30min 189ms
 Invocation: eb1b438d25564e3b9ff290276b946557
    Process: 6369 ExecStart=/usr/lib/drkonqi-coredump-processor --settle-first --pickup --uid 1000 (code=>
   Main PID: 6369 (code=killed, signal=TERM)
   Mem peak: 2.3M
        CPU: 49ms

Apr 09 18:10:03 arch-plasma systemd[1277]: Started Consume pending crashes using DrKonqi.
Apr 09 18:40:03 arch-plasma systemd[1277]: drkonqi-coredump-pickup.service: Service reached runtime time>
Apr 09 18:40:03 arch-plasma systemd[1277]: drkonqi-coredump-pickup.service: Failed with result 'timeout'.

keescase · April 9, 2025, 5:07pm

There is not much I can tell but I don’t have it installed in EOS.
Probably you also checked out this page

cactux · April 9, 2025, 5:44pm

@keescase thanks for referencing that page. I hadn’t look at it so it gave some useful information.

Check it’s enabled: systemctl is-enabled drkonqi-coredump-processor@.service

You can enable it with systemctl enable drkonqi-coredump-processor@.service

The user socket also needs to be present systemctl --user is-enabled drkonqi-coredump-launcher.socket

And can be enabled with systemctl --user enable --now drkonqi-coredump-launcher.socket

The first service mentioned was indeed disabled. Interesting that the --user service came with enabled preset. If the two of them are necessary for this crash report mechanism to work perhaps the system service needs to have the preset enabled. If users install this is for some reason I mean.

 cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h

From the last boot:


$ journalctl -b | grep -i drkonqi
Apr 09 19:18:10 arch-plasma systemd[1174]: Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/var/lib/sddm/.cache/drkonqi/sentry-envelopes/*).
Apr 09 19:18:10 arch-plasma systemd[1174]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Apr 09 19:18:19 arch-plasma systemd[1283]: Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/home/neotux/.cache/drkonqi/sentry-envelopes/*).
Apr 09 19:18:19 arch-plasma systemd[1283]: Listening on Socket to launch DrKonqi for a systemd-coredump crash.
Apr 09 19:18:20 arch-plasma systemd[1283]: Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/home/neotux/.cache/drkonqi/sentry-envelopes/*).
Apr 09 19:18:22 arch-plasma systemd[1283]: Started Consume pending crashes using DrKonqi.
Apr 09 19:19:11 arch-plasma systemd[2125]: Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/root/.cache/drkonqi/sentry-envelopes/*).
Apr 09 19:19:11 arch-plasma systemd[2125]: Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).

I am not sure what to make of this but it seems that it is being skipped because of some unmet condition, (ConditionUser=!@system)?

keescase · April 10, 2025, 9:01am

Have done some more research on this whole drkonqi thing and I noticed that drkonqi has kcrash as a dependency while kcrash has drkonqi only as an optional dependecy. Now drkonqi is not installed by default on EOS while kcrash is. Now this is just an observation no idea what to think of it further on

cactux · April 10, 2025, 2:57pm

Thank you so much @keescase for the support! I’m being away from that KDE Plasma box at the moment. I’ll have a look with this new clue and see if I can get it to work. If not DrKonqi will go to digital trash can.

RokeJulianLockhart · October 31, 2025, 6:16pm

@cactux, I also see this on Fedora 43:

17:56:09 systemd[116838]: Started drkonqi-sentry-postman.path - Submitting pending crash events (file monitor).
17:56:09 systemd[116838]: drkonqi-coredump-cleanup.timer - Cleanup lingering KCrash metadata was skipped because of an unmet condition check (ConditionPathExistsGlob=/var/lib/sddm/.cache/kcrash-metadata/*.ini).
17:56:09 systemd[116838]: drkonqi-sentry-postman.timer - Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/var/lib/sddm/.cache/drkonqi/sentry-envelopes/*).
17:56:09 systemd[116838]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
17:56:09 systemd[116838]: drkonqi-coredump-cleanup.service - Cleanup lingering KCrash metadata was skipped because of an unmet condition check (ConditionPathExistsGlob=/var/lib/sddm/.cache/kcrash-metadata/*.ini).
17:56:19 systemd[116838]: Stopped drkonqi-sentry-postman.path - Submitting pending crash events (file monitor).

From observation of the results that searching the string via Google returns, ^[1] this appears to accompany SDDM handoff failures. That seems like a coincidence, but it’s certainly when I noticed this. ^[2]

I’ve since located the report for it: