Bug 433293 - Some KDE processes (like kdeconnectd) are not killed after session logout, hog CPU
Summary: Some KDE processes (like kdeconnectd) are not killed after session logout, ho...
Status: RESOLVED FIXED
Alias: None
Product: ksmserver
Classification: Plasma
Component: general (show other bugs)
Version: 5.21.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: David Edmundson
URL:
Keywords:
: 437911 444131 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-02-20 07:22 UTC by Bharadwaj Raju
Modified: 2021-12-23 12:35 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24


Attachments
Stack trace obtained by forcing kdeconnectd to dump core (SIGSEGV) (3.04 KB, text/plain)
2021-02-21 06:36 UTC, Bharadwaj Raju
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bharadwaj Raju 2021-02-20 07:22:22 UTC
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.
Comment 1 Thiago Sueto 2021-02-20 12:07:01 UTC
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)
Comment 2 Thiago Sueto 2021-02-20 20:41:36 UTC
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?
Comment 3 Thiago Sueto 2021-02-20 22:39:35 UTC
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.
Comment 4 Bharadwaj Raju 2021-02-20 22:42:12 UTC
(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.
Comment 5 Bharadwaj Raju 2021-02-20 22:46:44 UTC
But it might still be interesting to kill -SIGSEGV the hanging processes to see exactly what they're stuck on.
Comment 6 Thiago Sueto 2021-02-20 22:49:50 UTC
(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?
Comment 7 Bharadwaj Raju 2021-02-21 06:33:47 UTC
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.
Comment 8 Bharadwaj Raju 2021-02-21 06:36:22 UTC
Created attachment 135997 [details]
Stack trace obtained by forcing kdeconnectd to dump core (SIGSEGV)
Comment 9 Weng Xuetian 2021-03-08 01:41:11 UTC
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..
Comment 10 Marco Ambu 2021-03-08 10:22:41 UTC
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.
Comment 11 Bharadwaj Raju 2021-03-09 14:01:52 UTC
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.
Comment 12 Bharadwaj Raju 2021-03-09 14:19:27 UTC
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).
Comment 13 Nate Graham 2021-03-09 15:48:00 UTC
So the problem is fixed for you now?
Comment 14 Marco Ambu 2021-03-09 16:23:52 UTC
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
Comment 15 Nate Graham 2021-03-09 16:55:19 UTC
That is not relevant to the bug being reported here. Please ask in a Debian-specific venue.
Comment 16 Bharadwaj Raju 2021-03-09 18:32:18 UTC
(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.
Comment 17 Nate Graham 2021-03-09 18:36:50 UTC
OK, thanks.
Comment 18 Weng Xuetian 2021-03-09 18:37:48 UTC
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.
Comment 19 Weng Xuetian 2021-03-09 18:57:05 UTC
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.
Comment 20 Bharadwaj Raju 2021-05-10 10:37:19 UTC
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?
Comment 21 Lyubomir 2021-07-03 19:43:44 UTC
I still experience this with KDE 5.22.2, Frameworks 5.83.0 and Qt 5.15.2.
Comment 22 Marco Rebhan 2021-07-31 13:30:23 UTC
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.
Comment 23 Lyubomir 2021-09-12 12:47:03 UTC
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?
Comment 24 Bharadwaj Raju 2021-09-12 13:02:42 UTC
(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.
Comment 25 Aleix Pol 2021-11-09 12:17:33 UTC
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
Comment 26 Nate Graham 2021-11-12 16:18:23 UTC
*** Bug 444131 has been marked as a duplicate of this bug. ***
Comment 27 Lyubomir 2021-12-23 12:35:28 UTC
*** Bug 437911 has been marked as a duplicate of this bug. ***