SUMMARY Some processes (I have seen kdeconnectd, others report krunner, yakuake as well) are not killed after Wayland* session logout, and consume huge amounts of CPU resources in the new session. Multiple reports: https://old.reddit.com/r/kde/comments/lnscdt/kdeconnectd_hogs_cpu/ https://old.reddit.com/r/kde/comments/lmlt58/help_arch_521_since_update_4_processes_hogging/ STEPS TO REPRODUCE 1. Login to Wayland session (note: it may be that bug only happens if you test Wayland as different user) 2. Do some stuff 3. Log out 4. Login to X11 session. OBSERVED RESULT Everything is slow. Check KSysGuard, see kdeconnectd and some other KDE processes of the wayland user hogging CPU. EXPECTED RESULT All KDE processes of old user are killed properly. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION The bug can be worked-around by telling logind to KillUserProcesses in /etc/systemd/logind.conf, but this only works if user has just one session open, the graphical one. Any TTY sessions open for example will cause it to not kill processes. pereira_alex said that systemdBoot did not fix the issue. Later I'll try it myself and report. * It may not be specific to logging out of Wayland, but all the reports I've seen are about Wayland.
It seems specific to logging out of Wayland. Logging out of X11 to an X11 or Wayland session works. I can confirm that systemdBoot doesn't fix the issue. I noticed that many of those faulty processes render core dumps, but every time this issue is reproduced different core dumps are created. The usual apps whose processes are left dangling are xdg-desktop-portal-kde, kdeconnectd, korgac, yakuake, kded5, drkonqi, kwalletd5, kactivitymanagerd. It might also happen with pretty much all Akonadi resources and agents. The processes that generate core dumps get signal ABRT, and I just noticed they all get the crash at the same place. Here's the core dump for kded5 for example: PID: 2400 (kded5) UID: 1000 (blumen) GID: 100 (users) Signal: 6 (ABRT) Timestamp: Sat 2021-02-20 08:53:57 -03 (8min ago) Command Line: /usr/bin/kded5 Executable: /usr/bin/kded5 Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kded.service Unit: user@1000.service User Unit: plasma-kded.service Slice: user-1000.slice Owner UID: 1000 (blumen) Boot ID: 5ed85749729948f1a866dd9e2dd865de Machine ID: bb51621ac9f84d7d8fc66a4adfeb7d93 Hostname: localhost.localdomain Storage: /var/lib/systemd/coredump/core.kded5.1000.5ed85749729948f1a866dd9e2dd865de.2400.1613822037000000.zst Message: Process 2400 (kded5) of user 1000 dumped core. Stack trace of thread 2400: #0 0x00007fe73ad200cb pthread_sigmask@@GLIBC_2.32 (libc.so.6 + 0x870cb) #1 0x00007fe73acd675d sigprocmask (libc.so.6 + 0x3d75d) #2 0x00007fe73bee5feb _ZN6KCrash15setCrashHandlerEPFviE (libKF5Crash.so.5 + 0x4feb) #3 0x00007fe73bee7e8a _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x6e8a) #4 0x00007fe73acd6520 __restore_rt (libc.so.6 + 0x3d520) #5 0x00007fe73acd6495 raise (libc.so.6 + 0x3d495) #6 0x00007fe73acbf864 abort (libc.so.6 + 0x26864) #7 0x00007fe73b13c0e7 qt_message_fatal (libQt5Core.so.5 + 0xbb0e7) #8 0x00007fe737adaf79 _ZNK15QtWaylandClient15QWaylandDisplay10checkErrorEv (libQt5WaylandClient.so.5 + 0x70f79) #9 0x00007fe737ae9e0a _ZN15QtWaylandClient15QWaylandDisplay13flushRequestsEv (libQt5WaylandClient.so.5 + 0x7fe0a) #10 0x00007fe73b38e9b0 _Z10doActivateILb0EEvP7QObjectiPPv (libQt5Core.so.5 + 0x30d9b0) #11 0x00007fe73b3af92c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x32e92c) #12 0x00007fe73b356d1b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2d5d1b) #13 0x00007fe73b35ef90 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2ddf90) #14 0x000056536b317412 n/a (kded5 + 0x7412) #15 0x00007fe73acc0b25 __libc_start_main (libc.so.6 + 0x27b25) #16 0x000056536b317b8e n/a (kded5 + 0x7b8e) Stack trace of thread 2441: #0 0x00007fe73b3af849 postEventSourcePrepare (libQt5Core.so.5 + 0x32e849) #1 0x00007fe739ea8742 g_main_context_prepare (libglib-2.0.so.0 + 0x54742) #2 0x00007fe739ea919b n/a (libglib-2.0.so.0 + 0x5519b) #3 0x00007fe739ea938f g_main_context_iteration (libglib-2.0.so.0 + 0x5538f) #4 0x00007fe73b3af90b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x32e90b) #5 0x00007fe73b356d1b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2d5d1b) #6 0x00007fe73b175dbe _ZN7QThread4execEv (libQt5Core.so.5 + 0xf4dbe) #7 0x00007fe73b176f01 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xf5f01) #8 0x00007fe73a8f0299 start_thread (libpthread.so.0 + 0x9299) #9 0x00007fe73ad99af3 __clone (libc.so.6 + 0x100af3) Stack trace of thread 2405: #0 0x00007fe739efa579 g_mutex_lock (libglib-2.0.so.0 + 0xa6579) #1 0x00007fe739ea9254 n/a (libglib-2.0.so.0 + 0x55254) #2 0x00007fe739ea938f g_main_context_iteration (libglib-2.0.so.0 + 0x5538f) #3 0x00007fe73b3af90b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x32e90b) #4 0x00007fe73b356d1b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2d5d1b) #5 0x00007fe73b175dbe _ZN7QThread4execEv (libQt5Core.so.5 + 0xf4dbe) #6 0x00007fe73b6f97b7 n/a (libQt5DBus.so.5 + 0x1b7b7) #7 0x00007fe73b176f01 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xf5f01) #8 0x00007fe73a8f0299 start_thread (libpthread.so.0 + 0x9299) #9 0x00007fe73ad99af3 __clone (libc.so.6 + 0x100af3) Stack trace of thread 2412: #0 0x00007fe73ad8ecdf __poll (libc.so.6 + 0xf5cdf) #1 0x00007fe739ea926e n/a (libglib-2.0.so.0 + 0x5526e) #2 0x00007fe739ea938f g_main_context_iteration (libglib-2.0.so.0 + 0x5538f) #3 0x00007fe739ea93e1 n/a (libglib-2.0.so.0 + 0x553e1) #4 0x00007fe739ed23ce n/a (libglib-2.0.so.0 + 0x7e3ce) #5 0x00007fe73a8f0299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007fe73ad99af3 __clone (libc.so.6 + 0x100af3) Stack trace of thread 2416: #0 0x00007fe73ad8ecdf __poll (libc.so.6 + 0xf5cdf) #1 0x00007fe739ea926e n/a (libglib-2.0.so.0 + 0x5526e) #2 0x00007fe739ea938f g_main_context_iteration (libglib-2.0.so.0 + 0x5538f) #3 0x00007fe72f4f559d n/a (libdconfsettings.so + 0x659d) #4 0x00007fe739ed23ce n/a (libglib-2.0.so.0 + 0x7e3ce) #5 0x00007fe73a8f0299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007fe73ad99af3 __clone (libc.so.6 + 0x100af3) Stack trace of thread 2413: #0 0x00007fe73ad8ecdf __poll (libc.so.6 + 0xf5cdf) #1 0x00007fe739ea926e n/a (libglib-2.0.so.0 + 0x5526e) #2 0x00007fe739ea95cb g_main_loop_run (libglib-2.0.so.0 + 0x555cb) #3 0x00007fe734f70b76 n/a (libgio-2.0.so.0 + 0x120b76) #4 0x00007fe739ed23ce n/a (libglib-2.0.so.0 + 0x7e3ce) #5 0x00007fe73a8f0299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007fe73ad99af3 __clone (libc.so.6 + 0x100af3) Stack trace of thread 2471: #0 0x00007fe739efa579 g_mutex_lock (libglib-2.0.so.0 + 0xa6579) #1 0x00007fe739ea8a8e g_main_context_check (libglib-2.0.so.0 + 0x54a8e) #2 0x00007fe739ea9215 n/a (libglib-2.0.so.0 + 0x55215) #3 0x00007fe739ea938f g_main_context_iteration (libglib-2.0.so.0 + 0x5538f) #4 0x00007fe73b3af90b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x32e90b) #5 0x00007fe73b356d1b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2d5d1b) #6 0x00007fe73b175dbe _ZN7QThread4execEv (libQt5Core.so.5 + 0xf4dbe) #7 0x00007fe73b176f01 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xf5f01) #8 0x00007fe73a8f0299 start_thread (libpthread.so.0 + 0x9299) #9 0x00007fe73ad99af3 __clone (libc.so.6 + 0x100af3)
I noticed I get the exact same backtrace for this issue as https://bugs.kde.org/show_bug.cgi?id=430335 . Perhaps both are caused by the same underlying issue?
Sorry, please ignore my comment about the backtrace in bug 430335 being the same. I was under the wrong assumption that the crashed thread was the last shown by the debugger, but I got this clarified to me over #kde-bugs.
(In reply to Thiago Sueto from comment #3) > Sorry, please ignore my comment about the backtrace in bug 430335 being the > same. I was under the wrong assumption that the crashed thread was the last > shown by the debugger, but I got this clarified to me over #kde-bugs. So the backtrace given in Comment 1 is unrelated, right? Because I never had crashes/coredumps with these processes while experiencing this issue.
But it might still be interesting to kill -SIGSEGV the hanging processes to see exactly what they're stuck on.
(In reply to Bharadwaj Raju from comment #4) > (In reply to Thiago Sueto from comment #3) > > Sorry, please ignore my comment about the backtrace in bug 430335 being the > > same. I was under the wrong assumption that the crashed thread was the last > > shown by the debugger, but I got this clarified to me over #kde-bugs. > > So the backtrace given in Comment 1 is unrelated, right? Because I never had > crashes/coredumps with these processes while experiencing this issue. Naw, I was referring specifically to the one in 430335. In the case of the report I'm commenting on right now, I always get core dumps whenever I reproduce this issue. The command coredumpctl list reports nothing after relogin for you?
Now that I check, there's indeed a whole lot of things which crashed. In order of their appearance in coredumpctl: baloo_file, kwalletd5, drkonqi, kded5, drkonqi repeated x3, DiscoverNotifier, drkonqi, plasmashell, org_kde_powerdevil x2, DiscoverNotifier, kded5, plasmashell. All processes were from my Wayland test user. The processes that were still running from the Wayland user after logout: kdeconnectd, baloorunner, drkonqi x2, sd-pam, gvfsd, systemd, gvfsd-fuse, dconf-service, agent, dbus-daemon. Also, I can confirm systemdBoot indeed doesn't help. I also manually kill -SIGSEGV'd the kdeconnectd process (it did not crash on its own, just hogged CPU), and am attaching the backtrace.
Created attachment 135997 [details] Stack trace obtained by forcing kdeconnectd to dump core (SIGSEGV)
While it is totally legit to "exit" on wayland compositor exits for Qt application, for X11 error X11 client just exits instead of "abort" (signal 6). signal 6 triggers drkonqi, but actually the problem is drkonqi is also stucked due to compositor is gone... I wonder if drkonqi could handle this more kindly..
Since you mentioned drkonqi, can this be related to bug #433293? I have the same issue described in that ticket as well where on logoff, some processes are not stopped and start hogging the CPU when I re-login.
Processes are left over from Wayland user even after uninstalling drkonqi (kcrash is still installed, as it is a dependency of several KDE programs). Although I don't see kdeconnectd running anymore, may or may not be related to uninstalling drkonqi. Will check.
After reinstalling drkonqi, there's still no kdeconnectd hanging on anymore (it is still shown as crashed in coredumpctl - crashed processes don't live on, of course).
So the problem is fixed for you now?
How can you remove drkonqi without removing the entire KDE? I am using debian bullseye and if I try to remove it I am told all the packages that will need to be removed as well: The following packages will be REMOVED: drkonqi kde-plasma-desktop kde-standard kinfocenter plasma-desktop plasma-widgets-addons plasma-workspace plasma-workspace-wayland task-kde-desktop I have the same issue with this: KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2
That is not relevant to the bug being reported here. Please ask in a Debian-specific venue.
(In reply to Nate Graham from comment #13) > So the problem is fixed for you now? No, since other processes are still alive, even kdeconnectd is not closed properly, it segfaults. And from what I can tell, the only reason some program either crashes or remains alive is a matter of chance (race condition etc). So I can't call this fixed. (In reply to Marco Ambu from comment #14) > How can you remove drkonqi without removing the entire KDE? Arch allows me to do so, as rest of KDE does not hard-depend on drkonqi.
OK, thanks.
I'm on arch and I kinda aware of this issue for some time. 1. Qt would capture wayland error upon logout, and it triggers SIGABRT, because it will call qFatal(). 2. This SIGABRT would trigger drkonqi, but drkonqi would likely to freeze at this point because wayland compositor is quiting. 3. The "crashed" app would simply wait for drkonqi for the instruction. I also observed two different kind of drkonqi freeze a. it stucked in Qt wayland for querying some font settings, potentially a bug in Qt. When this happens, it will also hog the CPU. b. it stucked in KIdleTime's wayland plugin. In order to avoid this, following approaches may be tried 1. Fix Qt wayland by not triggering abort. While the wayland error is "fatal", it doesn't seems to be worth to use qFatal and leave some coredump, something like _exit might just work. At least we know that XIOError on X11 won't trigger qFatal. 2. don't install drkonqi (not so good resolution but an easy workaround for current user) 3. Fix drkonqi to make it not do anything related to GUI upon logout. I noticed that drkonqi has code that monitoring ksmserver, but apparently it doesn't work in this wayland logout case. 4. Fix kidletime's wayland plugin and fix qt wayland for the freeze issue.
Sent https://codereview.qt-project.org/c/qt/qtwayland/+/338188 for trying approach 1 mentioned above. But I guess we should also try to see if this can be avoided within drkonqi code.
Might be fixed? On Neon Unstable, all processes of the old user are killed when logging out of a Wayland session (apparently they all crashed when KWin exited I guess, I can see them in coredumpctl). Can anyone reproduce this on Unstable or similar git master builds?
I still experience this with KDE 5.22.2, Frameworks 5.83.0 and Qt 5.15.2.
Can confirm still happening on Plasma 5.22.4, Frameworks 5.84.0, Qt 5.15.2 on Gentoo. A list of processes it leaves behind for me is korgac, konversation, kconnectd, akonadi_*_resource, akonadiserver, startplasma-waylandsession, baloo_file, pipewire, pipewire-media-session, kdeinit5, kdeinit5_shutdown, klauncher. Note that pipewire is the only non-KDE software here but Plasma autostarts it so it should probably kill it on logout too. Only konversation, korgac, kconnectd and the akonadi processes take up CPU resources though. baloo_file might be left behind on X as well, I'm not sure.
This is a show-stopper for Wayland by default. Is this fixed in some Qt version or somewhere else? Is it on some backlog? I mean, i see some important bugs fixed, but also a lot of cosmetic bugs fixed before this one. Why not first fix all the big bugs and then the cosmetic ones?
(In reply to Lyubomir from comment #23) > This is a show-stopper for Wayland by default. Is this fixed in some Qt > version or somewhere else? Is it on some backlog? I mean, i see some > important bugs fixed, but also a lot of cosmetic bugs fixed before this one. > Why not first fix all the big bugs and then the cosmetic ones? KDE does not have a central authority dictating where developer time must go. Developers are mostly volunteers, and they work on whatever they feel like, whatever interests or affects them.
Git commit f377696bff39e35ae0f7ae6104d8732b3856744e by Aleix Pol Gonzalez, on behalf of Aleix Pol. Committed on 09/11/2021 at 12:17. Pushed by apol into branch 'master'. startplasma: Make sure we terminate the processes we start Changes how plasma_session works. Instead of just starting the processes, plays the startup sound and stays around. This process then gets to be terminated as the session ends. Related: bug 359651 M +14 -23 startkde/CMakeLists.txt M +4 -6 startkde/plasma-session/CMakeLists.txt A +47 -0 startkde/plasma-session/sessiontrack.cpp [License: LGPL(v2.0)] A +22 -0 startkde/plasma-session/sessiontrack.h [License: LGPL(v2.0)] A +60 -0 startkde/plasma-session/signalhandler.cpp [License: LGPL(v2.0)] A +38 -0 startkde/plasma-session/signalhandler.h [License: LGPL(v2.0)] M +35 -3 startkde/plasma-session/startup.cpp M +15 -0 startkde/plasma-session/startup.h M +1 -1 startkde/startplasma-waylandsession.cpp M +18 -16 startkde/startplasma.cpp M +1 -1 startkde/startplasma.h M +9 -0 startkde/waitforname/main.cpp https://invent.kde.org/plasma/plasma-workspace/commit/f377696bff39e35ae0f7ae6104d8732b3856744e
*** Bug 444131 has been marked as a duplicate of this bug. ***
*** Bug 437911 has been marked as a duplicate of this bug. ***