[ABANDONED] Help Needed to Assist KDE Debug Glacially Slow Wayland Wakeup from Sleep

[TheSupremeVizier]

This pertains to this post I made earlier: https://www.kubuntuforums.net/forum/...-systemd-crash

I have filed multiple bugs with KDE and this is one of them. I am trying to enable collection of coredumps. Towards this goal, I have installed systemd-coredump. I have also modified /etc/systemd/coredump.conf and /etc/security/limits.conf. I have verified that core dumps are saved by opening an xterm, determining it's PID, executing "kill -SEGV <xterm PID>" and then executing "sudo coredumpctl list", observing

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

and then also observing the following inside ~/.cache/drkonqi/crashes/

xterm.4a49651c1dd34c1ab5b67588c9b4e414.32388.1758821663000000.ini

Granted, this is not a core file, but I suspect it provides useful information that leads to a core file in /var/lib/systemd/coredump/.

HOWEVER, the problem is in enabling coredumps that are apparently explicitly disabled by existing configured system-level code. What do I mean? Look at the following statements extracted from "sudo journalctl -b 0 -r":

Sep 25 14:38:11 <hostname> systemd[44767]: drkonqi-sentry-postman.timer - Submitting pending crash events was skipped because of an unmet condition check (ConditionPathExistsGlob=/home/<username>/.cache/drkonqi>

Sep 25 14:38:10 <hostname> systemd[44675]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).​

I do not understand why the unmet condition check "(ConditionPathExistsGlob=/home/<username>/.cache/drkonqi>" is present given the appearance of xterm info in ~/.cache/drkonqi/crashes/ . How do I fix this?

I also do not know where to find the system code requiring modification to remove the unment condition check "(ConditionUser=!@system)". Can you tell me where the code requiring modification resides? I assume this is either a configuration file or a shell script and it is not written in code requiring compilation.

[TheSupremeVizier]

I did my best to allow user AND system-level core dumps to occur. This included ensuring the installation of systemd-coredump, modifying /etc/systemd/system.conf and /etc/systemd/user.conf while setting DefaultLimitCORE=infinity, ensuring that /etc/systemd/coredump.conf included

[Coredump]
Storage=external
MaxUse=2G

(or greater), ensuring that /proc/sys/kernel/core_pattern contained

|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

ensuring "ulimit -c unlimited" is applied and enforced, then executing

sudo systemctl daemon-reexec
sudo systemctl restart systemd-coredump
sudo systemctl daemon-reload

So I'm going to assume that I did pretty much everything I could do to enable core dumps from user and system processes.
I then recreated the problem issue.
I then verified that there were no core dumps using "coredumpctl list".
I performed "ps uax" and grep'd the output for [Pp]lasma and [Ww]ayland.
I executed "top" and saw nothing out of the ordinary.
Nothing slapped me in the face as a problem, other than the disgusting problem issue was still present, making working inside Wayland to be between a PITA and impossible.

And after doing all this, I executed
sudo journalctl -b 0 -r
and observed many replicants of the following line

Oct 04 15:59:41 <hostname> systemd[13365]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).

As such, I must assume that debugging this issue is beyond my current capability and knowledge.