Tumbleweed crashes with report on bootup

Hi Group,

I just noticed that when I boot my computer I receive a notification that there was some sort of crash. The notice also has a link to view the crash report.

Note that the computer boots and runs normally, except for leaving the crash notification. I don’t know what the report is telling me and I certainly don’t know how to deal with it. Can anyone help?

Crash Report text follows:

UID: 1000 (ken)
GID: 1000 (ken)
Signal: 6 (ABRT)
Timestamp: Thu 2026-07-02 13:43:41 +07 (5s ago)
Command Line: /usr/libexec/drkonqi-coredump-launcher -session 1028c1d320b210000178295382700000020040003_1782957110_491396
Executable: /usr/libexec/drkonqi-coredump-launcher
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-\x2fusr\x2flibexec\x2fdrkonqi\x2dcoredump\x2dlauncher@66de8b2744784525ade871fbe8e161b0.service
Unit: user@1000.service
User Unit: app-\x2fusr\x2flibexec\x2fdrkonqi\x2dcoredump\x2dlauncher@66de8b2744784525ade871fbe8e161b0.service
Slice: user-1000.slice
Owner UID: 1000 (ken)
Boot ID: 8665c05b9fae44d78109212899a8b1fc
Machine ID: 546178bbbaff497eb17febf26f1037a4
Hostname: localhost.localdomain
Storage: /var/lib/systemd/coredump/core.drkonqi-coredum.1000.8665c05b9fae44d78109212899a8b1fc.2307.1782974621000000.zst (present)
Size on Disk: 1.3M
Message: Process 2307 (drkonqi-coredum) of user 1000 dumped core.

            Stack trace of thread 2307:
            #0  0x00007f7f7269cebc __pthread_kill_implementation (libc.so.6 + 0x9cebc)
            #1  0x00007f7f72641f86 raise (libc.so.6 + 0x41f86)
            #2  0x00007f7f726293a0 abort (libc.so.6 + 0x293a0)
            #3  0x00007f7f72efd17f n/a (libQt6Core.so.6 + 0xfd17f)
            #4  0x00007f7f72efecc3 _ZNK14QMessageLogger5fatalEPKcz (libQt6Core.so.6 + 0xfecc3)
            #5  0x000055b522529e96 n/a (drkonqi-coredump-launcher + 0x9e96)
            #6  0x00007f7f7262b33e __libc_start_call_main (libc.so.6 + 0x2b33e)
            #7  0x00007f7f7262b46b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2b46b)
            #8  0x000055b52252a195 n/a (drkonqi-coredump-launcher + 0xa195)

            Stack trace of thread 2317:
            #0  0x00007f7f726a3892 __syscall_cancel_arch (libc.so.6 + 0xa3892)
            #1  0x00007f7f72697418 __internal_syscall_cancel (libc.so.6 + 0x97418)
            #2  0x00007f7f72697471 __syscall_cancel (libc.so.6 + 0x97471)
            #3  0x00007f7f72710eb2 ppoll (libc.so.6 + 0x110eb2)
            #4  0x00007f7f720d04ef n/a (libglib-2.0.so.0 + 0x644ef)
            #5  0x00007f7f720d0c60 g_main_context_iteration (libglib-2.0.so.0 + 0x64c60)
            #6  0x00007f7f732ac1a8 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Core.so.6 + 0x4ac1a8)
            #7  0x00007f7f72fe9a33 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0x1e9a33)
            #8  0x00007f7f730f5855 _ZN7QThread4execEv (libQt6Core.so.6 + 0x2f5855)
            #9  0x00007f7f72d73cde n/a (libQt6DBus.so.6 + 0x44cde)
            #10 0x00007f7f73190460 n/a (libQt6Core.so.6 + 0x390460)
            #11 0x00007f7f7269af30 start_thread (libc.so.6 + 0x9af30)
            #12 0x00007f7f7271ec2c __clone3 (libc.so.6 + 0x11ec2c)

            Stack trace of thread 2319:
            #0  0x00007f7f726a3892 __syscall_cancel_arch (libc.so.6 + 0xa3892)
            #1  0x00007f7f72697418 __internal_syscall_cancel (libc.so.6 + 0x97418)
            #2  0x00007f7f72697471 __syscall_cancel (libc.so.6 + 0x97471)
            #3  0x00007f7f7271092a __poll (libc.so.6 + 0x11092a)
            #4  0x00007f7f717282a4 n/a (libxcb.so.1 + 0xf2a4)
            #5  0x00007f7f71729d4c xcb_wait_for_event (libxcb.so.1 + 0x10d4c)
            #6  0x00007f7f6f9b1068 n/a (libQt6XcbQpa.so.6 + 0x64068)
            #7  0x00007f7f73190460 n/a (libQt6Core.so.6 + 0x390460)
            #8  0x00007f7f7269af30 start_thread (libc.so.6 + 0x9af30)
            #9  0x00007f7f7271ec2c __clone3 (libc.so.6 + 0x11ec2c)
            ELF object binary architecture: AMD x86-64

I had a look at my own system

> sudo systemctl list-units --state=failed
[sudo] password for root: 
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.
> systemctl --user list-units --state=failed
  UNIT                            LOAD   ACTIVE SUB    DESCRIPTION                          
● drkonqi-coredump-pickup.service loaded failed failed Consume pending crashes using DrKonqi

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

1 loaded units listed.

So it looks like on my system DrKonqi itself crash, that is quite ironic DrKonqi is supposed to help collecting debug information if another application is crashing.

Checking further:

> systemctl status --user drkonqi-coredump-pickup.service
× drkonqi-coredump-pickup.service - Consume pending crashes using DrKonqi
     Loaded: loaded (/usr/lib/systemd/user/drkonqi-coredump-pickup.service; disabled; preset: disabled)
     Active: failed (Result: timeout) since Sat 2026-07-04 07:29:52 CEST; 14min ago
   Duration: 30min
 Invocation: 213776041d0b4d7abb35bb01c621f293
    Process: 4199 ExecStart=/usr/libexec/drkonqi-coredump-processor --settle-first --pickup --uid 1000 (code=killed, signal=TERM)
   Main PID: 4199 (code=killed, signal=TERM)
        CPU: 70ms

Jul 04 06:59:52 systemd[1838]: Started Consume pending crashes using DrKonqi.
Jul 04 07:29:52 systemd[1838]: drkonqi-coredump-pickup.service: Service reached runtime time limit. Stopping.
Jul 04 07:29:52 systemd[1838]: drkonqi-coredump-pickup.service: Failed with result 'timeout'.

What is remarkable is “disabled; preset: disabled” but it still Started.

I tried:

> systemctl start --user drkonqi-coredump-pickup.service
> systemctl status --user drkonqi-coredump-pickup.service

And then it is running fine.

My theory: DrKonqi is started somewhere during the boot process but it is too early and therefore it errors out.

It this the same for your system?

Does anybody have an idea why/how drkonqi-coredump-pickup is started while it is disabled?

1 Like

Then the conclusion is that it is NOT on boot, but during or after login of user ken. Which is a huge difference when it comes to bug hunting.

Seeing similar issue for some time.

Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
           PID: 14202 (drkonqi-coredum)
           UID: 1069 (jonzn4SUSE)
           GID: 1000 (jonzn4SUSE)
        Signal: 6 (ABRT)
     Timestamp: Sun 2026-06-28 00:51:29 EDT (6 days ago)
  Command Line: /usr/libexec/drkonqi-coredump-launcher
    Executable: /usr/libexec/drkonqi-coredump-launcher
 Control Group: /user.slice/user-1069.slice/user@1069.service/app.slice/drkonqi-coredump-launcher@23-28675-14192_25730-0.service
          Unit: user@1069.service
     User Unit: drkonqi-coredump-launcher@23-28675-14192_25730-0.service
         Slice: user-1069.slice
     Owner UID: 1069 (jonzn4SUSE)
       Boot ID: b42b5e3e55454c1bb37ed96f6b2d6aac
    Machine ID: 30a3d9b326334a909dee643d5ce696a3
      Hostname: ProBook-455-G9
       Storage: /var/lib/systemd/coredump/core.drkonqi-coredum.1069.b42b5e3e55454c1bb37ed96f6b2d6aac.14202.1782622289000000.zst (present)
  Size on Disk: 763.1K
       Message: Process 14202 (drkonqi-coredum) of user 1069 dumped core.
                
                Stack trace of thread 14202:
                #0  0x00007f406089d87c __pthread_kill_implementation (libc.so.6 + 0x9d87c)
                #1  0x00007f40608424c6 raise (libc.so.6 + 0x424c6)
                #2  0x00007f40608293a0 abort (libc.so.6 + 0x293a0)
                #3  0x00007f40610fd17f n/a (libQt6Core.so.6 + 0xfd17f)
                #4  0x00007f40610fecc3 _ZNK14QMessageLogger5fatalEPKcz (libQt6Core.so.6 + 0xfecc3)
                #5  0x00007f4061981384 n/a (libQt6Gui.so.6 + 0x181384)
                #6  0x00007f4061a31fc8 _ZN22QGuiApplicationPrivate21createEventDispatcherEv (libQt6Gui.so.6 + 0x231fc8)
                #7  0x00007f40611e1e8d _ZN23QCoreApplicationPrivate4initEv (libQt6Core.so.6 + 0x1e1e8d)
                #8  0x00007f4061a320d2 _ZN22QGuiApplicationPrivate4initEv (libQt6Gui.so.6 + 0x2320d2)
                #9  0x00007f4061a2e876 _ZN15QGuiApplicationC1ERiPPci (libQt6Gui.so.6 + 0x22e876)
                #10 0x0000563fefe1bf6f n/a (drkonqi-coredump-launcher + 0x8f6f)
                #11 0x00007f406082b33e __libc_start_call_main (libc.so.6 + 0x2b33e)
                #12 0x00007f406082b46b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2b46b)
                #13 0x0000563fefe1d195 n/a (drkonqi-coredump-launcher + 0xa195)
                ELF object binary architecture: AMD x86-64

Operating System: openSUSE Tumbleweed 20260623
KDE Plasma Version: 6.7.0
KDE Frameworks Version: 6.27.0
Qt Version: 6.11.1
Kernel Version: 7.0.12-1-default (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 5825U with Radeon Graphics
Memory: 64 GiB of RAM (62.1 GiB usable)
Graphics Processor: AMD Radeon Graphics
Manufacturer: HP
Product Name: HP ProBook 455 15.6 inch G9 Notebook PC
System Version: SBKPFV3

The notification pops up once the computer finishes booting. Thats all I know.

Those two lines of code don’t mean anything to me. If they mean something to you then could you kindly turn the information into something I can do to resolve this?

Thank you.

Ken Alexander

So Phisai, Thailand OK18sc

Interesting. How did you resolve it?

Ken
So Phisai, Thailand OK18sc

When it “pops up” there is already a graphical session running. Which means that someone (ken in this case) is logged in. Probably you have automatic login for ken configured, but that is still a login and no boot anymore.

It also means ken is running a desktop environment, that appears to be KDE Plasma, but you failed to tell us.

Also there might be one component that reports a crash, but that does not mean that “Tumbleweed crashes”. As you say yourself:

So Tumbleweed runs fine.

Yes, I auto login. I need to reboot the computer late at night in order to run a few things that won’t work unless the computer has rebooted.

I didn’t fail to tell you I was running Plasma. I just didn’t know it was relevant. If Plasma has an effect on the appearance of the errors please let me know so I can understand how they are related.

Yes, Tumbleweed appears to run just fine, which makes these errors all the more difficult to understand, and so far, still impossible to resolve.

Ken
So Phisai, Thailand OK18sc

Hi Marel,

I’m looking at this again in the hope that I have learned something in the meantime.

“Disabled; preset: disabled” What’s that mean in plain English?

Are you saying you fixed this error by running the systemctl start… and systemctl status… lines and the DrKonqi errors permanently disappeared? If so, where did you run them? In the Terminal? I know there’s some sort of UEFI terminal thing in the BIOS. Maybe you ran it there? Can you let me know?

You had a theory that DrKonqi was starting too early in the boot process, and then asked “Is this the same for your system?”. I don’t know. I barely understand what DrKonqi’s purpose is. But if I run the same commands shown in your message, and get the same responses, then could I say it’s the same in my system and we could go from there?

Regards

Ken
So Phisai, Thailand OK18sc

It means the unit file exists and can be started, but it is not enabled to start automatically for your user session.
disabled = currently not set to auto-start; preset: disabled = the distro’s default policy also says it should not be auto-enabled.

Found out that units can also be started by other units so that is likely going on. Checked more things:

> systemctl --user list-units | grep drkonqi
  drkonqi-sentry-postman.path             loaded active waiting   Submitting pending crash events (file monitor)
● drkonqi-coredump-pickup.service         loaded failed failed    Consume pending crashes using DrKonqi
  drkonqi-coredump-launcher.socket        loaded active listening Socket to launch DrKonqi for a systemd-coredump crash
  drkonqi-coredump-cleanup.timer          loaded active waiting   Cleaning DrKonqi data

No, I did not fix the problem yet, but based on the output above it could be that during the boot a crash happens and that triggers DrKonqi and also DrKonqi crashes but that looks to not the case:

> sudo systemctl list-units --state=failed
[sudo] password for root: 
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

> systemctl --user list-units --state=failed
  UNIT                            LOAD   ACTIVE SUB    DESCRIPTION                          
● drkonqi-coredump-pickup.service loaded failed failed Consume pending crashes using DrKonqi

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

1 loaded units listed.

No failed system units, only the user DrKonqi service “reached runtime time limit.”.

> systemctl --user cat drkonqi-coredump-pickup.service
<snip>
[Service]
ExecStart=/usr/libexec/drkonqi-coredump-processor --settle-first --pickup --uid %U
RuntimeMaxSec=30 minutes

And for me that 30 minutes hit:

> sudo journalctl -b | grep -i drkonqi
[sudo] password for root: 
Jul 05 07:35:55 systemd[1789]: Started Cleaning DrKonqi data.
Jul 05 07:35:55 systemd[1789]: Submitting pending crash events skipped, unmet condition check ConditionPathExistsGlob=/home/user/.cache/drkonqi/sentry-envelopes/*
Jul 05 07:35:55 systemd[1789]: Listening on Socket to launch DrKonqi for a systemd-coredump crash.
Jul 05 07:35:55 systemd[1789]: Cleaning DrKonqi data skipped, no trigger condition checks were met.
Jul 05 07:35:56 systemd[1789]: Submitting pending crash events skipped, unmet condition check ConditionPathExistsGlob=/home/user/.cache/drkonqi/sentry-envelopes/*
Jul 05 07:35:59 systemd[1789]: Started Consume pending crashes using DrKonqi.
Jul 05 08:06:12 systemd[1789]: drkonqi-coredump-pickup.service: Service reached runtime time limit. Stopping.
Jul 05 08:06:12 systemd[1789]: drkonqi-coredump-pickup.service: Failed with result 'timeout'.
Jul 05 08:55:10 drkonqi-coredump-gui[10987]: QML debugging is enabled. Only use this in a safe environment.
Jul 05 08:57:44 systemd[1789]: app-org.kde.drkonqi.coredump.gui@13741572b91541b8af463e3a22d47440.service: Consumed 2.157s CPU time over 2min 34.319s wall clock time.

New theory, drkonqi starts during user boot, checks and does see it still need to do something but “unmet condition check” some conditions were not met.

I did a rm -rf /home/$USER/.cache/drkonqi/ and will check next boot what that gives.

Deleting /home/$USER/.cache/drkonqi/ did not work, still the boot log shows:

Jul 06 10:03:19 systemd[1759]: Started Cleaning DrKonqi data.
Jul 06 10:03:19 systemd[1759]: Submitting pending crash events skipped, unmet condition check ConditionPathExistsGlob=/home/$USER/.cache/drkonqi/sentry-envelopes/*
Jul 06 10:03:19 systemd[1759]: Listening on Socket to launch DrKonqi for a systemd-coredump crash.
Jul 06 10:03:19 systemd[1759]: Cleaning DrKonqi data skipped, no trigger condition checks were met.
Jul 06 10:03:20 systemd[1759]: Submitting pending crash events skipped, unmet condition check ConditionPathExistsGlob=/home/$USER/.cache/drkonqi/sentry-envelopes/*
Jul 06 10:03:23 systemd[1759]: Started Consume pending crashes using DrKonqi.

The home/$USER/.cache/drkonqi/ directory is NOT recreated.

Next try, sudo zypper rm drkonqi6, that should be prevent the problem.

Hi Marel,

I don’t know if this helps you, but I tried running some of the commands in Terminal that you did. These are my results:

ken@192:~> sudo systemctl list-units --state=failed
[sudo] password for root:
UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.
ken@192:~> systemctl --user list-units --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.
ken@192:~> systemctl status --user drkonqi-coredump-pickup.service
○ drkonqi-coredump-pickup.service - Consume pending crashes using DrKonqi
Loaded: loaded (/usr/lib/systemd/user/drkonqi-coredump-pickup.service; disabled; preset: disabled)
Active: inactive (dead) since Mon 2026-07-06 15:55:18 +07; 3min 23s ago
Duration: 1min 3.866s
Invocation: e1dae4466f664b90b6a5f251564b3427
Process: 2164 ExecStart=/usr/libexec/drkonqi-coredump-processor --settle-first --pickup --uid 1000 (code=exited, sta>
Main PID: 2164 (code=exited, status=0/SUCCESS)
CPU: 100ms

Jul 06 15:55:17 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/libexec/drkonqi-coredump-launcher” 2378 "/var/lib/s>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/bin/kmail” 6816 "/var/lib/systemd/coredump/core.kma>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/libexec/drkonqi-coredump-launcher” 2314 "/var/lib/s>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/libexec/drkonqi-coredump-launcher” 2319 "/var/lib/s>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/libexec/drkonqi-coredump-launcher” 3558 "/var/lib/s>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/libexec/drkonqi-coredump-launcher” 3559 "/var/lib/s>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/bin/kmail” 3563 "/var/lib/systemd/coredump/core.kma>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/libexec/drkonqi-coredump-launcher” 2424 "/var/lib/s>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/bin/kmail” 2427 "/var/lib/systemd/coredump/core.kma>
Jul 06 15:55:18 192.168.1.14 drkonqi-coredump-processor[2164]: “/usr/bin/kmail” 2439 "/var/lib/systemd/coredump/core.kma>
log file: ystemctl status --user drkonqi-coredump-pickup.service

Let me know if this is useful to you. Incidentally, I rebooted 3 or 4 times in a row and the DRKonqi crash message disappeared. I didn’t do anything on the computer between reboots. Let me try again after doing a few things.

Hi Marel,

Just did a zypper update , a few other things and then rebooted. No Dr Konqi crash message. I don’t know if it was the zypper update that did it or something else. Let me know if there’s anything else I can do to help, but for now it looks like things might have fixed themselves.

I’m still having problems with another issue that gives an error when I boot. I’ll post the error message when I transcribe the text from the photo screenshot I grabbed.

Many thanks,

Hi Marel,

This is the other error I get every time my computer boots:

[ 0.202962][ T1] ACPI BIOS Error (bug): Failure creating named object [\SB.PCI0.GP.XHC0._PRW], AE_ALREADY EXISTS (20251212/dswloadZ-326)
[ 0.202978][ T1] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20251212/psobject-220)
[ 0.203001][ T1] ACPI BIOS Error (bug): Failure creating named object [\SB.PCIO.GP17XHC!._PRW] AE_ALREADY_EXISTS (20251212/dswloadZ-326)
[ 0.203004][ T1] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20251212/psobject-220)
[ 0.203039][ T1] ACPI BIOS Error (bug): Failure creating named object [\GPE._L191], AE_ALREADY_EXISTS (20251212/dswloadZ-326)
[ 0.203042][ T1] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20251212/psobject-220)

Hope you can help. No worries if you can’t or don’t want to!

Could you please use preformatted text ( the </> in the message editor ). This kind of output is unreadable compared to that.

@marel I got hit by this too. Like you said, removing ~/.cache/drkonqi doesn’t help. But … I removed ~/.local/share/drkonqi and guess what? 3 Reboots and no crashes !!!

For that error better create a new topic, and doing so, please indicate if there are any other side effects apart from the two error line.

@ve3hls Check for a system BIOS update, else add loglevel=2 to the kernel boot options to ignore, but you might want to peruse the boot log ever now and again for possible errors. But “2” will suppress the ACPI ones.

Like I wrote I did deinstall drkonq6 and yes, that solved the problem. Then deleted (also) ~/.local/share/drkonqi and did re-install drkonq6 but the next reboot does still show:

> sudo journalctl -b | grep -i drkonqi
Jul 07 19:46:59 systemd[1747]: Started Cleaning DrKonqi data.
Jul 07 19:46:59 systemd[1747]: Submitting pending crash events skipped, unmet condition check ConditionPathExistsGlob=/home/emvee/.cache/drkonqi/sentry-envelopes/*
Jul 07 19:46:59 systemd[1747]: Listening on Socket to launch DrKonqi for a systemd-coredump crash.
Jul 07 19:46:59 systemd[1747]: Cleaning DrKonqi data skipped, no trigger condition checks were met.
Jul 07 19:47:00 systemd[1747]: Submitting pending crash events skipped, unmet condition check ConditionPathExistsGlob=/home/emvee/.cache/drkonqi/sentry-envelopes/*
Jul 07 19:47:03 systemd[1747]: Started Consume pending crashes using DrKonqi.
Jul 07 20:17:03 systemd[1747]: drkonqi-coredump-pickup.service: Service reached runtime time limit. Stopping.
Jul 07 20:17:03 systemd[1747]: drkonqi-coredump-pickup.service: Failed with result 'timeout'.

So no crash but somehow DrKonqi is started with no good reason as far as I can see.

This is what I see now:

knurpht@Lenovo-P16:~/.config> sudo journalctl -b | grep -i drkon | grep -i failed
knurpht@Lenovo-P16:~/.config>