Bug 359651 - Dangling user processes after KDE session crash
Summary: Dangling user processes after KDE session crash
Status: RESOLVED FIXED
Alias: None
Product: ksmserver
Classification: Plasma
Component: general (show other bugs)
Version: 5.19.2
Platform: Arch Linux Linux
: NOR crash
Target Milestone: ---
Assignee: Lubos Lunak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-21 22:21 UTC by Bernie Innocenti
Modified: 2021-11-09 16:08 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernie Innocenti 2016-02-21 22:21:00 UTC
After killing a KDE session, several processes remain dangling around:

bernie     877  0.0  0.0  45216  4816 ?        Ss   Feb20   0:00 /usr/lib/systemd/systemd --user
bernie     884  0.0  0.1 189548 13244 ?        S    Feb20   0:00 /usr/bin/kwalletd --pam-login 14 18 --nofork
bernie   21949  0.0  0.9 1660192 75676 ?       Sl   Feb20   0:25 kded5 [kdeinit5]
bernie    4295  0.0  0.0      0     0 ?        Z    15:13   0:00  \_ [ibus] <defunct>
bernie   22319  0.0  0.3 338740 26176 ?        S    Feb20   0:00 /usr/bin/kuiserver5
bernie   23897  0.0  0.0 170644  3028 ?        Ss   Feb20   0:02 gpg-agent --homedir /home/bernie/.gnupg --use-standard-socket --daemon
bernie    4482  0.0  1.4 3168140 112336 ?      Tl   15:16   0:05 /usr/bin/plasmashell -s --crashes 1


Reproducible: Always

Steps to Reproduce:
This scenario can easily be reproduced by killing the X server with CTRL-ALT-BS.


Actual Results:  
This leads to confusing / malfunctioning behavior in subsequent KDE sessions. The only fix for non-technical users is rebooting the machine.

Expected Results:  
The entire process tree under kdeinit / ksmserver should be killed.
Comment 1 Bernie Innocenti 2016-02-21 22:24:04 UTC
This bug could be refiled under the kdeframeworks-kinit component. Not sure which one is responsible for session cleanup.
Comment 2 Bernie Innocenti 2017-06-09 04:19:14 UTC
Still present in Plasma 5.10.1. Also present in Archlinux.
Comment 3 Bernie Innocenti 2019-10-30 06:15:11 UTC
Even though the session is now managed by systemd, I still see an entire dangling session when logging out from a Plasma session:

bernie  889  Ss  /usr/lib/systemd/systemd --user
bernie  890  S    \_ (sd-pam)
bernie  901  Ss   \_ /usr/bin/ssh-agent -a /run/user/1000/ssh-agent.socket
bernie  911  Ss   \_ /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
bernie  965  Sl   \_ /usr/lib/dconf-service
bernie 1048  Ssl  \_ /usr/lib/gvfsd
bernie 1058  Sl   \_ /usr/lib/gvfsd-fuse /run/user/1000/gvfs -f
bernie 1118  Ssl  \_ /usr/lib/at-spi-bus-launcher
bernie 1125  S    |   \_ /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address
bernie 1126  Ssl  \_ /usr/lib/xdg-desktop-portal
bernie 1131  Ssl  \_ /usr/lib/xdg-document-portal
bernie 1134  Ssl  \_ /usr/lib/xdg-permission-store
bernie 1203  Ssl  \_ /usr/bin/pipewire
bernie 1240  Ss   \_ /usr/lib/bluetooth/obexd
bernie 1039  Sl  /usr/lib/geoclue-2.0/demos/agent
Comment 4 Bernie Innocenti 2020-05-10 12:51:06 UTC
Perhaps this bug will be fixed by this commit?

https://github.com/sddm/sddm/commit/9ce5bd6e62b2fd1f96421b9797e64181883d15c3
Comment 5 Bernie Innocenti 2020-05-10 12:52:29 UTC
David, do you reckon your recent commit to SDDM will fix this bug?
Comment 6 David Edmundson 2020-05-10 12:59:32 UTC
Yeah but I might end up reverting it.

Have you tried logind's KillUserProcesses option?
Comment 7 Bernie Innocenti 2020-06-29 13:33:11 UTC
This is still happening with latest sddm and plasma-workspace

bernie2    11301  0.0  0.0  19552 10620 ?        Ss   22:28   0:00 /usr/lib/systemd/systemd --user
bernie2    11302  0.0  0.0 194380  3596 ?        S    22:28   0:00  \_ (sd-pam)
bernie2    11322  0.0  0.0 267340  3268 ?        Ss   22:28   0:00  \_ /usr/bin/dbus-broker-launch --scope user
bernie2    11323  0.0  0.0   5048  3200 ?        S    22:28   0:00  |   \_ dbus-broker --log 4 --controller 10 --machine-id 6ed6dbe65a274a909e5e7af2f4570b62 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000
bernie2    11325  0.0  0.0 236908  7364 ?        Ssl  22:28   0:00  \_ /usr/lib/gvfsd
bernie2    11330  0.0  0.0 382412  7816 ?        Sl   22:28   0:00  \_ /usr/lib/gvfsd-fuse /run/user/1001/gvfs -f
bernie2    11423  0.0  0.0 154920  3624 ?        Ssl  22:28   0:00  \_ /usr/lib/dconf-service
bernie2    11554  0.0  0.0  44176  6820 ?        Ss   22:28   0:00  \_ /usr/lib/bluetooth/obexd
bernie2    11924  0.6  0.0 158500  9244 ?        S<sl 22:29   0:00  \_ /usr/bin/pulseaudio --daemonize=no
bernie2    11940  0.0  0.0 238104  9600 ?        Sl   22:30   0:00      \_ /usr/lib/pulse/gsettings-helper
bernie2    11451  0.0  0.1 268668100 26068 ?     SNl  22:28   0:00 /home/bernie/kde/usr/bin/baloo_file
bernie2    11501  0.0  0.0 234140  5036 ?        Sl   22:28   0:00 /usr/lib/geoclue-2.0/demos/agent
Comment 8 Nate Graham 2020-09-29 03:33:41 UTC
*** Bug 422322 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2020-09-29 03:34:05 UTC
*** Bug 417889 has been marked as a duplicate of this bug. ***
Comment 10 Nate Graham 2020-09-29 03:34:36 UTC
This is being worked in in a generic way via the systemd slices and cgroup work.
Comment 11 David Edmundson 2020-09-29 22:45:00 UTC
*** Bug 427111 has been marked as a duplicate of this bug. ***
Comment 12 S. Bryant 2020-09-30 07:06:33 UTC
This is reproducible under openSUSE Leap 15.2 with Plasma 5.19.90 (prebuilt RPMs).

I have two systems here.  The list of dangling processes on each is not identical to each other.

I tested a little: on one machine, killing only kio_http_cache_cleaner resulted in the other dangling processes exiting without needing to be killed.  This is reproducible on that machine.

On the other machine, some processes still remained after killing kio_http_cache_cleaner.  I was able to trigger them exiting by killing kwin_x11 I think (didn't make a note).

Perhaps they don't exit because they're still waiting for the bus.
Comment 13 Nate Graham 2020-10-12 03:38:34 UTC
*** Bug 362142 has been marked as a duplicate of this bug. ***
Comment 14 Nate Graham 2020-10-12 03:45:37 UTC
*** Bug 244250 has been marked as a duplicate of this bug. ***
Comment 15 Aleix Pol 2021-11-09 12:17:25 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 433293

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