SUMMARY I have found poor behavior of Wayland when compared to X11 in the areas of post-sleep wakeup restoration. STEPS TO REPRODUCE System should be a fresh install that has never run X11. Problem with respect to Wayland sleep and awakening. 1. Before I run what follows, I go to System Settings > Appearance & Style > Colors & Themes > Login Screen (SDDM) and I choose "Kubuntu" and enter whatever image I want into "Change Background". 2. I also start gkrellm and set the sticky bit. (This is done by right-clicking on the gkrellm titlebar, and in the resulting popup selecting "General", the "Properties" tab and then selecting "Set sticky state", then click "Apply" or "OK".) Leave gkrellm running on the display. 3. Next place the system running Wayland into sleep mode. 4. Wake from sleep mode. OBSERVED RESULT Waking from sleep mode is glacially slow and does not fully recover. Returning from sleep mode I am greeted with a black desktop within which I can move a cursor and see nothing else. EXPECTED RESULT Waking from sleep mode should require a short time duration. The user should be greeted with a normal login desktop. 5. I hit Control-Alt-F2 and see no change. (There is no change because Wayland has placed the display at the Control-Alt-F2 position.) 6. I hit Control-Alt-F3 and I am presented with a virtual terminal window and login. 7. I hit Control-Alt-F1 and now see two login screens using the background image I specified. The login screens are not completely filled out compared to the original login screens, meaning the username and user avatar image are not presented…just a black hole instead of an avatar image. Clearly, waking from sleep mode should either move to the Control-Alt-F1 screen instead of the Control-Alt-F2 screen, or Wayland should default to use Control-Alt-F2 instead of Control-Alt-F1 for login, similar to X11. 8. Login. OBSERVED RESULT: Recovery of the desktop display is glacially slow. The areas previously occupied by gkrellm (sticky bit set to cover all virtual desktops) are black and remain so indefinitely. Time and date are not displayed in the taskbar contrary to the default. I opened Konsole and executed “sudo journalctl -b 0 -r” and looked for “crash”. Gadzillions of crash statements associated with systemd. This is not an issue with X11. From the journalctl output: Sep 23 12:10:46 <hostname> systemd[6172]: drkonqi-coredump-launcher.socket: Unit needs to be started because active unit sockets.target upholds it, but not starting since we tried this too often recently. Will retry later. Sep 23 12:10:46 <hostname> systemd[6172]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system). [repeats the last statement at least 16 times and the first statement once, and does so every ten seconds] Expected Result: Very fast waking and recovery from sleep mode. This is not an issue with X11. EXPECTED RESULT Recovery of the desktop display should be prompt and gkrellm should be visible and functioning. Time and date should be displayed in the taskbar. This is not an issue with X11. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 25.04, Linux 6.14.0-32-generic #32-Ubuntu SMP PREEMPT_DYNAMIC KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 ADDITIONAL INFORMATION HARDWARE: CPU: AMD Ryzen 9 9900X GPU: NVIDIA GeForce RTX 5070 Mboard: MSI PRO B650-VC WIFI III RAM: 32 GB DDR5 2 x 2 TB SSD WD_BLACK SN850X HS 2000GB w/ heatsink Dual identical resolution monitors used side-by-side forming single desktop.
It seems plasmashell crashed. Can you please check and if this is the case attach a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl?
(In reply to David Redondo from comment #1) > It seems plasmashell crashed. > Can you please check and if this is the case attach a backtrace of the > crash using the coredumpctl command-line program, as detailed in > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl? coredumpctl is not installed on my Kubuntu 25.04 system. If I install coredumpctl on my system now, will it retrieve the information you seek which might have been generated before coredumpctl installation?
Created attachment 185268 [details] attachment-1926536-0.html Hi, David. coredumpctl is not installed on my Kubuntu 25.04 system. If I install coredumpctl on my system now, will it retrieve the information you seek which might have been generated before coredumpctl installation? Thanks, Steve On Thursday, September 25, 2025 at 02:13:58 AM CDT, David Redondo <bugzilla_noreply@kde.org> wrote: https://bugs.kde.org/show_bug.cgi?id=509870 David Redondo <kde@david-redondo.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |NEEDSINFO CC| |kde@david-redondo.de Resolution|--- |WAITINGFORINFO --- Comment #1 from David Redondo <kde@david-redondo.de> --- It seems plasmashell crashed. Can you please check and if this is the case attach a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl?
Within X11 I executed sudo apt install systemd-coredump I then logged out and logged back in using Wayland. I then verified that coredumpctl was installed by opening a small xterm, determining its PID, then executing kill -SEGV <xterm PID> and then executing sudo coredumpctl list This provided the following output: TIME PID UID GID SIG COREFILE EXE SIZE Thu 2025-09-25 12:34:23 CDT 32388 1000 1000 SIGSEGV present /usr/bin/xterm 332.1K So coredumpctl is installed and functional. I then put the system into sleep mode. I then woke the system from sleep mode. Much weird display behavior is observed while moving the mouse cursor over the display. I eventually log in. I then execute sudo coredumpctl list and am again provided with the following output: TIME PID UID GID SIG COREFILE EXE SIZE Thu 2025-09-25 12:34:23 CDT 32388 1000 1000 SIGSEGV present /usr/bin/xterm 332.1K Apparently either nothing has crashed, or something is masking the crashing executable from being detected as a crash or saved as a coredump. To support this assumption, I provide the following excerpt from the execution of sudo journalctl -b 0 -r Sep 25 12:35:53 Gargantuan systemd[32919]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system). If you can tell me (1) where and how to modify software to disable this condition check, I assume that (2) I can later revert this change and regain normal system operation. After performing the modification implied in item (1), I will again attempt to generate the coredump in Wayland.
(In reply to steve_garnier from comment #3) > Created attachment 185268 [details] > attachment-1926536-0.html > > Hi, David. coredumpctl is not installed on my Kubuntu 25.04 system. If I > install coredumpctl on my system now, will it retrieve the information you > seek which might have been generated before coredumpctl installation? > Thanks, Steve > On Thursday, September 25, 2025 at 02:13:58 AM CDT, David Redondo > <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=509870 > > David Redondo <kde@david-redondo.de> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REPORTED |NEEDSINFO > CC| |kde@david-redondo.de > Resolution|--- |WAITINGFORINFO > > --- Comment #1 from David Redondo <kde@david-redondo.de> --- > It seems plasmashell crashed. > Can you please check and if this is the case attach a backtrace of the crash > using the coredumpctl command-line program, as detailed in > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl? Please respond to my comment dated 2025-09-24 15:05:28 UTC. I see no evidence of a plasma crash. Thank you.
(In reply to David Redondo from comment #1) > It seems plasmashell crashed. > Can you please check and if this is the case attach a backtrace of the > crash using the coredumpctl command-line program, as detailed in > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl? Hi, David. Please respond to my comment dated 2025-09-24 15:05:28 UTC. I see no evidence of a plasma crash. How am I supposed to provide you with core dump information when the apparent crash generated the following journalctl statement? "Sep 25 12:35:53 Gargantuan systemd[32919]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system)." Interpretation of this journalctl statement appears to indicate that if the crash occurs on a system process (and NOT a user process) that a core dump will not be generated. How do I get around this in order to provide you with a core dump? Thank you. Steve
Sorry I can't tell you a way to check if something has crashed I am not using kubuntu please check somewhere else how to see crash reports on Kubuntu. Without a bakxtrace this is sadly not actionable for us