Bug 27147 - Plasma sessions are not clean up after logoff, lead to after successive logins that plasmashell is not loaded properly.
Summary: Plasma sessions are not clean up after logoff, lead to after successive login...
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: Mageia 9
Assignee: KDE maintainers
QA Contact:
URL:
Whiteboard:
Keywords: IN_ERRATA8
Depends on:
Blocks: 17523
  Show dependency treegraph
 
Reported: 2020-08-20 11:34 CEST by Aurelien Oudelet
Modified: 2024-08-22 22:59 CEST (History)
7 users (show)

See Also:
Source RPM:
CVE:
Status comment: kglobalaccel stuff still broken under Magiea 8


Attachments
journalctl -b -1 output when doing tests (69.39 KB, application/x-xz)
2020-08-20 11:34 CEST, Aurelien Oudelet
Details
ksysguard: still running process belonging to no longer connected user (325.68 KB, image/png)
2020-08-24 00:00 CEST, Aurelien Oudelet
Details

Description Aurelien Oudelet 2020-08-20 11:34:01 CEST
Created attachment 11812 [details]
journalctl -b -1 output when doing tests

Today with Cauldron up to date, I do tests following:

1 - Login from sddm (graphical.target) on user1 (uid 1000), desktop 
environment is Plasma 5.
2- Do something within desktop (open app for example).
3- Logout from menus as usual. And go back to sddm.
4- Log on user2 (uid 1001), Plasma session and do something inside like open 
firefox.
5- Log out and go back sddm.
6- Put system to sleep with icon in sddm.
7- Wait several minutes and put system runs with press any key.
8- sddm displays his menu.
9- Log on user1 (uid 1000)
10- See plasmashell not running: black background, mouse OK, autostart apps 
like Konversation open without window decoration, unmovable, KRunner (alt-F2) 
is OK to run apps but they can't be moved.

What I see in journal each time I do plasmashell in Konsole:
plasmashell[8896]: requesting unexisting screen -1
plasmashell[8896]: requesting unexisting screen -1

Ctrl+alt+Backspace 2 times repeated well Zap Xorg server and go well back on 
sddm.

Rebooting system their is a complain:
user2 still logged on seat0
user3 still logged on seat0
Do systemctl reboot -i to ignore inhibitors.

I rebooted there after and after reboot, first session runs fine. Sleep and 
Resume is OK if I don't log out my account.

I can retry this behavior at every try. If system goes to sleep with only sddm 
at tty1, every plasma session launched after don't permit plasmashell from 
running.

Config:
Operating System: Mageia 8
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.8.2-desktop-2.mga8
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6600K CPU @ 3.50GHz
Memory: 15.6 Gio of RAM
Graphics Processor: GeForce GTX 1660 Ti/PCIe/SSE2

Nvidia nonfree drivers are running version
x11-driver-video-nvidia-current-450.57-3.mga8.nonfree.x86_64

I see this behavior after each system sleep when there is only sddm on tty1:
background of sddm is no longer blurry and each user log on results of no 
plasmashell running when session is opened.

Assigning to sddm maintainers (KDE team) and even basesystem for additional forensics.
Comment 1 Aurelien Oudelet 2020-08-23 23:56:14 CEST
After carefully reading my logs... I see sessions are not properly closed.

$ loginctl list-sessions
SESSION  UID USER     SEAT  TTY
     c2 1000 aurelien seat0    
     c4 1002 enfants  seat0    
     c6 1000 aurelien seat0    

Normally c2 and c4 sessions must be closed and no longer seen while c6 exists.
I am not using fast-userswitching here.

systemd misconfiguration? sddm was c1, c3 and c5 session.
Added attachment from Ksysguard.
Comment 2 Aurelien Oudelet 2020-08-24 00:00:04 CEST
Created attachment 11825 [details]
ksysguard: still running process belonging to no longer connected user

In Ksysguard:

There are running process belonging to no longer connected user.
In this case, they belong to user "enfant" who is no longer connected to what ever TTY.

TTY1 (graphical) is user 1000 (aurelien) and no other TTY has a graphical session.
Comment 3 José Jorge 2020-08-24 08:58:31 CEST
I confirm this bug. After closing a user session, I have to kill the following processes manually :
- /usr/lib/systemd/systemd --user
- gpgagent
- sshagent
- /usr/libexec/geoclue-2.0/demos/agent

CC: (none) => lists.jjorge

Aurelien Oudelet 2020-10-29 16:13:22 CET

Blocks: (none) => 17523

Aurelien Oudelet 2020-12-26 16:53:11 CET

Source RPM: sddm-0.18.1-4.mga8.src.rpm => sddm-0.19.0-3.mga8.src.rpm

Comment 4 Aurelien Oudelet 2021-01-11 11:17:25 CET
I do think the issue is in how Plasma handles a logout. Instead of killing definitely all Plasma applications, some are still here and wait for X11 server...

Also, some don't properly die on exit.
This is in process to be managed by systemd scope in Plasma 5.21 (Optional).

Also, this upstream fixed bug:
https://bugs.kde.org/show_bug.cgi?id=429426

this is still present in our distribution.
Comment 5 Aurelien Oudelet 2021-01-11 11:25:55 CET
I also wonder why X server complains about missing logind integration when running sddm although this not affect GDM and GNOME.

In /var/log/Xorg.0.log

[    19.081] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration

If this is provided, a logout in Plasma results of properly handle all remaining user process.

Target Milestone: --- => Mageia 8
Source RPM: sddm-0.19.0-3.mga8.src.rpm => kglobalaccel-5.76.0-1.mga8.src.rpm
CC: lists.jjorge => (none)

Comment 6 Aurelien Oudelet 2021-01-28 10:02:48 CET
Partially fixed.
kglobalaccel5 will no longer trigger a relaunch of itself will session is logged out. Fix backported by David Geiger. Thank you so much.

If you boot your system, log on to the first time via sddm to Plasma Desktop, your session is seen by systemd/logind as session "c2".

If you logout, or trigger "Ctrl + Alt + Backspace" twice :
Some process remains actives to the session c2 like:

- baloo_file (/etc/xdg/autostart/baloo_file.desktop)
which is owned by baloo-5.76.0-2.mga8.src.rpm

- geoclue (/etc/xdg/autostart/geoclue-demo-agent.desktop)
which is owned by geoclue-2.5.7-1.mga8.src.rpm

These two process are not killed when the Plasma session is logged off.

But, as far as I can see, the new Plasma session no longer make sooo loong time to startup next time.

Not as a side effect, that if you do a Ctrl + Alt + Backspace twice, this will deactivate the Plasma compositor on next logon. Even if you reactivate it under Plasma Systemsettings5 => Hardware => Display and Monitor => Compositor. You don't have full 3D accelerated session. This is the desired upstream behavior. You need to restart your session again...
Comment 7 Morgan Leijström 2021-02-05 20:44:05 CET
Added this bug to errata in a simple way, for now.

Keywords: (none) => IN_ERRATA8
CC: (none) => fri

Comment 8 Morgan Leijström 2021-02-22 18:58:06 CET
So for us who dont care about baloo or geoclue, we can simply remove that two .desktop files from autostart/ ?
Comment 9 Aurelien Oudelet 2021-02-22 19:12:38 CET
(In reply to Morgan Leijström from comment #8)
> So for us who dont care about baloo or geoclue, we can simply remove that
> two .desktop files from autostart/ ?

I think.
But something that normally cleans up the session at logout does not do its job.
I do think this is due to logind integration that is not working for Plasma.
If you see /var/log/Xorg.0.log you can see a complain about -keeptty not present and that logind integration is not enabled.
Comment 10 Aurelien Oudelet 2021-04-10 14:50:35 CEST
Additional fixes are landing in this:

https://bugs.kde.org/show_bug.cgi?id=429426

The kglobalaccel5 daemon can no longer block re-login by crashing on the previous log-out and then getting stuck (David Edmundson, Plasma 5.22 or Frameworks 5.82; whichever one you get first)
Comment 11 Giuseppe Ghibò 2021-04-29 13:22:31 CEST
I tried the workaround suggested in bug https://bugs.kde.org/show_bug.cgi?id=429426 under mga8 (plasma-workspace-5.20.4-5.mga8, kwin-5.20.4-3.mga8), by adding:

cat <<EOF > /etc/X11/xinit.d/99-reset-failed-user-service
#!/usr/bin/sh
# to be sourced
systemctl --user reset-failed
EOF
chmod 755 /etc/X11/xinit.d/99-reset-failed-user-service

or

cat <<EOF > /etc/X11/xinit/xinitrc.d/99-reset-failed-user-service
#!/usr/bin/sh
# to be sourced
systemctl --user reset-failed
EOF
chmod 755 /etc/X11/xinit/xinitrc.d/99-reset-failed-user-service

it mitigated a bit, but after 4-5 subsequent X11-Zapping (Ctrl-Alt-Backspace-Backspace) the plasma desktop hung at the progress bar of the splash screen as usual. Chances are higher if you press Ctrl-Alt-Backspace-Backspace as soon as you see the "panel" bar in the desktop screen.

To narrow stuff, you can also try without any desktop manager (sddm, etc.), using startx (as described in https://bugs.mageia.org/show_bug.cgi?id=27362#c16).

CC: (none) => ghibomgx

Comment 12 Giuseppe Ghibò 2021-04-29 14:35:35 CEST
I did a further experiment: build a plasma-workspace-5.20.4 with reverting these two upstream commits (the one cited in the RH bug):

https://invent.kde.org/plasma/plasma-workspace/-/commit/1e444c864fc175b3826c88a51a5e2c9f95e497c3

https://invent.kde.org/plasma/plasma-workspace/-/commit/77f418500e56e3227828d26619aeba462a5c8227

the resulting desktop mitigated further, however in my case after 12 Ctrl-Alt-Backspace-Backspace subsequent logins in a row, at 13th the plasma desktop timed out at the splash progress bar as usual.

IMHO the locking problems happens in different places.

Note that apparently kwin_x11 is not involved. A Plasma session can start even without a window manager. You might try this just renaming the binary /usr/bin/kwin_x11 to /usr/bin/kwin_x11_, and then start plasma. You get a full desktop starting with the panel bar (apart that windows can't be resized/moved), however after a certain amount of X11 subsequent zapping the hang on splash progress bar occur anyway.
Comment 13 Aurelien Oudelet 2021-05-19 13:21:23 CEST
In facts, the kglobalaccel5 stuff is the emerged part of the iceberg.

The Plasma session in his Mageia 8 implementation is broken. Not our fault, it is how Plasma handles background services/applications.

In current form, it loads them but they escape ksmserver/kdeinit server manager and they belong to systemd --user which is still running after a logoff.
When Plasma die on logoff, some binaries remain active (gpg-agent, at-spi stuff,...) All that need X11 are died properly (or not for kglobalaccel5 which respawn again 6 times).

This is silly. This leads to remaining sessions to consume resources and to conflict with later session as some background stuff can't properly register with the newer session.


BUT: great news: Plasma 5.21.5 and 5.22 have all of these fixed as soon as we use Plasma systemd start by issuing:

$ kwriteconfig5 --file startkderc --group General --key systemdBoot true

Rebooting and boh. All logoff are properly handle. Session is properly closed and there is no longer any remaining process.

Currently, upstream does not seem to fix the "classic" way to load Plasma which hacky but give a session... as long as user does not successive logoff/logon.

Side note/remark: The net_applet is properly handled in systemd starting way but his menu is still missing on Plasma X11. Will add more in its bug report.

Priority: Normal => release_blocker
Source RPM: kglobalaccel-5.76.0-1.mga8.src.rpm => (none)
Summary: Multi-users successive logins, plasmashell no longer runs log on to whatever user after going into sleep => Plasma sessions are not clean up after logoff, lead to after successive logins that plasmashell is not loaded properly.
Status comment: (none) => kglobalaccel stuff still broken under Magiea 8
Target Milestone: Mageia 8 => Mageia 9

Comment 14 John Klein 2022-05-21 12:15:05 CEST
> In facts, the kglobalaccel5 stuff is the emerged part of the iceberg.
> 
> The Plasma session in his Mageia 8 implementation is broken. Not our fault,
> it is how Plasma handles background services/applications.
> 
> In current form, it loads them but they escape ksmserver/kdeinit server
> manager and they belong to systemd --user which is still running after a
> logoff.
> When Plasma die on logoff, some binaries remain active (gpg-agent, at-spi
> stuff,...) All that need X11 are died properly (or not for kglobalaccel5
> which respawn again 6 times).
> 
> This is silly. This leads to remaining sessions to consume resources and to
> conflict with later session as some background stuff can't properly register
> with the newer session.
> 
> 
> BUT: great news: Plasma 5.21.5 and 5.22 have all of these fixed as soon as
> we use Plasma systemd start by issuing:
> 
> $ kwriteconfig5 --file startkderc --group General --key systemdBoot true
> 
> Rebooting and boh. All logoff are properly handle. Session is properly                     
> closed and there is  no longer any remaining process.
> Currently, upstream does not seem to fix the "classic" way to load Plasma          https://www.wildtornado.casino/en-AU               
> which hacky but give a session... as long as user does not successive
> logoff/logon.
> 
> Side note/remark: The net_applet is properly handled in systemd starting way                            
> but his menu is still missing on Plasma X11. Will add more in its bug report.

Thank you for this solution.

CC: (none) => Painololo

Comment 15 Lewis Goeroech 2022-08-27 21:41:20 CEST
On my Cauldron install, it's not just KDE Plasma refusing to load after the latest glibc and Qt library updates, but rather other Qt-based desktops like LXQt and Qt-based programs, too, like KDE Connect, qBittorrent, Protonup-Qt, CMake and many others.

GNOME, Cinnamon, other GTK desktops and GTK-based applications still work flawlessly after the update to said libraries.

Please fix the Qt toolchain as soon as possible, as it annoys me that I cannot use qBittorrent and my preferred desktop choice.

CC: (none) => grclajos

Comment 16 Morgan Leijström 2022-08-27 23:22:06 CEST
@Lewis G
Was the excess problems due to incnsistent toolchain, Bug 30780 ?
Comment 17 Lewis Goeroech 2022-08-27 23:27:03 CEST
(In reply to Morgan Leijström from comment #16)
> @Lewis G
> Was the excess problems due to incnsistent toolchain, Bug 30780 ?

If an unbootable KDE desktop and Qt apps refusing to load is showing signs of an incosistent Qt toolchain, then yes, it was.
Nicolas Lécureuil 2023-06-06 22:58:57 CEST

Priority: release_blocker => Normal
CC: (none) => mageia

Comment 18 Cyril Levet 2023-06-07 08:36:26 CEST
According to Comment 13, everything is fixed by using Plasma systemd start. It is now the default for our Plasma in Cauldron (5.27.5).
Unfortunately, I cannot test the whole procedure in Comment 1 (at least in VirtualBox) because I don't find how to put system sleep from sddm.

CC: (none) => cyril.levet0780

Comment 19 Morgan Leijström 2023-07-06 17:38:53 CEST
removed from errata9

Version: Cauldron => 8

Comment 20 Marja Van Waes 2024-08-22 22:59:18 CEST
We stopped supporting Mageia 8 almost 8 months ago 
https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/

That means we also stopped fixing Mageia 8 bugs and that this bug report needs to be closed, regardless of whether it was fixed for Mageia 8 or not.

If this particular bug did not get fixed for Mageia 8, then we do regret that.

If this issue is still present in Mageia 9 or cauldron, then please reopen this report, write a comment and adjust the "Version:" field.

If you are not yet a member of one or our teams, then please consider becoming one. https://wiki.mageia.org/en/Contributing
Mageia is a community project, meaning that we, the users, make Mageia together.

The more active contributors we have, the more bug reports will get fixed.
Besides, being active in a team can be very rewarding. It was and is certainly rewarding to me :-D

Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.