Issues after user switching from GUI, eg. logout/login

Support KDE Plasma
, ,
22

True but nowerdays its the default for 99%, and in Arch/Manjaro case it is the default…
BTW: I don’t use any containers yet…

Anyway i will try to remove the mymachines entry from the passwd and group lines to see if it helps…
My current contents as reference:

~ >>>  cat /etc/nsswitch.conf|xclip 
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files mymachines systemd
group: files mymachines systemd
shadow: files

publickey: files

hosts: files mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns mdns4 myhostname
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

[manjaro etc]# diff -u nsswitch.conf.dist nsswitch.conf 

--- nsswitch.conf.dist  2020-09-26 15:06:06.000000000 +0300
+++ nsswitch.conf       2020-10-13 10:26:11.767087981 +0300
@@ -1,8 +1,8 @@
 # Name Service Switch configuration file.
 # See nsswitch.conf(5) for details.
 
+passwd: files systemd
+group: files systemd
-passwd: files mymachines systemd
-group: files mymachines systemd
 shadow: files
 
 publickey: files

edit: Reverted the diff output i had posted :wink:

23

You’ll probably need to reload the configuration after that.

sudo systemctl daemon-reload named.service
24

I just rebooted just in case…
But anyhow, the problem still seems present.

I have to mention though that it does not happen every single time but often enough to be really bothered about it.
After this reboot i tried a few times to just login wait a few and logout wait a few and repeat.
After a few times 2+, the system got stuck at login.
When i switched to VT2 and ran htop i could see that a process /usr/bin/kwin_x11 was using almost 100% CPU…
After killing all processes of the login attempted user, i could once again login again as usual in the GUI.

So my conclusion is that this is not related to nsswitch.conf but more a problem with KDE/Plasma/SDDM?

25

@Aragorn
After the above i decide to take a closer look at this a bit more.
This time after a reboot but before a GUI login i loged in as root on VT2.
I started htop with the user switch to see the processes of the user i was about to login into the GUI.
Ofcourse at this time no processes would be shown.
I loged into the GUI waited a bit and loged out again.
To my suprise even though the user account loged out there were still processes running of it :confused:
This is the output i got on VT2 as root, while the user was loged out and thus only root should be loged in (on VT2):

ps -U 1000 -u 1000 u
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
<the_user>     1953  0.0  0.0  20608 10684 ?        Ss   11:34   0:00 /usr/lib/systemd/systemd --user
<the_user>     1954  0.0  0.0 179400  3440 ?        S    11:34   0:00 (sd-pam)
<the_user>     1975  0.0  0.0   7744  4944 ?        Ss   11:34   0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
<the_user>     1977  0.0  0.0 238756  7180 ?        Ssl  11:34   0:00 /usr/lib/gvfsd
<the_user>     1982  0.0  0.0 379000  6156 ?        Sl   11:34   0:00 /usr/lib/gvfsd-fuse /run/user/1000/gvfs -f
<the_user>     2051  0.0  0.0 154984  3792 ?        Sl   11:34   0:00 /usr/lib/dconf-service
<the_user>     2188  0.0  0.0 235908  5148 ?        Sl   11:34   0:00 /usr/lib/geoclue-2.0/demos/agent
<the_user>     2286  0.0  0.0  45188  6888 ?        Ss   11:34   0:00 /usr/lib/bluetooth/obexd
<the_user>     2309  0.0  0.0 304160  5912 ?        Ssl  11:35   0:00 /usr/lib/at-spi-bus-launcher
<the_user>     2318  0.0  0.0   7232  4404 ?        S    11:35   0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
<the_user>     2321  0.0  0.0 475144 13212 ?        Ssl  11:35   0:00 /usr/lib/xdg-desktop-portal
<the_user>     2328  0.0  0.0 530224  6344 ?        Ssl  11:35   0:00 /usr/lib/xdg-document-portal
<the_user>     2332  0.0  0.0 234656  4828 ?        Ssl  11:35   0:00 /usr/lib/xdg-permission-store
root        2337  0.0  0.0   2440  1788 ?        Ss   11:35   0:00 fusermount -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc
<the_user>     2383  0.0  0.0 106428 12968 ?        Ssl  11:35   0:00 /usr/bin/pipewire
<the_user>     2386  0.0  0.0  21248  8692 ?        Sl   11:35   0:00 /usr/bin/pipewire-media-session
<the_user>     2403  0.0  0.0 139648 17528 ?        Sl   11:35   0:00 /usr/bin/ksystemstats
<the_user>     2405  0.0  0.0   4208  2444 ?        S    11:35   0:00 /usr/bin/ksysguardd
<the_user>     2776  0.0  0.0 160724  7496 ?        Sl   11:36   0:00 /usr/lib/at-spi2-registryd --use-gnome-session
<the_user>     2777  0.0  0.1 277732 47028 ?        Sl   11:36   0:00 /usr/bin/plasmashell
<the_user>     2792  0.0  0.2 2271264 93488 ?       Sl   11:36   0:00 /usr/lib/xdg-desktop-portal-kde

I think this is the major cause of this problem…

PS: I reverted my change of nsswitch.conf after this again just in case…

26

I think it’s rather a symptom than the cause.

But you still haven’t tried removing the word systemd from the pertinent sections of your /etc/nsswitch.conf, as I recommended you would.

27

Just to please you, i just did that:

--- nsswitch.conf.dist	2020-09-26 15:06:06.000000000 +0300
+++ nsswitch.conf	2020-10-13 12:40:47.768917700 +0300
@@ -1,8 +1,8 @@
 # Name Service Switch configuration file.
 # See nsswitch.conf(5) for details.
 
-passwd: files mymachines systemd
-group: files mymachines systemd
+passwd: files mymachines
+group: files mymachines
 shadow: files
 
 publickey: files

But as i guessed it did not change anything, the problem is still the same as before.
(i undid it again after this experiment)

The same problem persists and im left unable to login to the GUI, it gets stuck…
In VT2 as root i can still see the same /usr/bin/kwin_x11 process using 100% CPU constantly.

Here is a camera shot of the processes that are left behind after a logout of the GUI by the user:
>>> htop -u xxxx

IMG_20201013_124712
IMG_20201013_124712912×684 387 KB

Seems the forum reduces the quality of the image, i still have the highres version if needed.
(Any recommended free image host that alows high-res full image sharing?)

Seems the solution provided here at least gets rid of the lingering processes after logout.

--- /etc/systemd/logind.conf.dist	2020-09-21 11:10:39.000000000 +0300
+++ /etc/systemd/logind.conf	2020-10-13 15:54:39.384803517 +0300
@@ -15,6 +15,7 @@
 #NAutoVTs=6
 #ReserveVT=6
 #KillUserProcesses=no
+KillUserProcesses=yes
 #KillOnlyUsers=
 #KillExcludeUsers=root
 #InhibitDelayMaxSec=5

After this change during my first testing i had some kind of lockup where i had to use [HowTo] reboot / turn off your frozen computer: REISUB/REISUO to reboot.
I had Steam set to auto start on login which i have now disabled which caused it…
So i will keep this topic open till i test more over time while this is active…

29

Have u tried the LTS kernel?

I can normally use 5.8.11 kernel but sometimes when restating the machine, it gets stuck with black screen ( only motherboard logo and mouse)…I have to restart the machine several times and then it starts normally (like nothing happened😅)…I am still searching for solutions…I can use Arch with kernel 5.8.11 - 5.8.14 just fine…no issue there

I tried Fedora… similar problems there​:thinking::thinking:
I can’t even install fedora from the latest isos and I can’t install Manjaro Linux58 isos either…:sweat_smile::sweat_smile:

One thing to note that the problem isn’t there with Manjaro window manager editions…(i3, bspwm, awesome, openbox…tried openbox)

30

I have not noticed any problem with any kernel yet…
PS: I see you’re using the 450 series driver for nVidia, i recomend you to use the 440 series…

1 Like
31

Back to topic:
For some reason i had to re-install manjaro because my BTRFS got corrupted.
No idea what the real reason was. (Most probably the issue was caused by the topic)
I used BTRFS inside LUKS2 + a swap partition inside a separate LUKS2, but in this temporary new install i dropped the LUKS2 of the BTRFS to see…

Will keep monitoring the solution mentioned last that seems to solve the topic for now…

32

linuxnews(.de) schreibt interessante Neuigkeiten zum KDE logout/login Problem:
“Plasma 5.21 erhält neue Startoption”

33

Hmm interesting to know, would be more interesting if it had a link :wink:

34

Sorry it’s not allowed to post links here. Just google for “Plasma 5.21 erhält neue Startoption”.

Or look for the blog of the main KDE developer David Edmundson and his article about the subject: “Plasma and the systemd startup”

35

It’s ok you can post the link later when your account reaches the needed trust level :wink:
But anyway a new start option has nothing to do with the problem in OP…

36

I’m not a Linux or Plasma expert. I thought that the subject of the mentioned articles are about how systemd and sddm start and stop the Plasmashell and other services.
And my poor understanding is that if you logout of Manjaro KDE than the Plasmashell and releated services will be terminated and on re-login they get started again.
That’s why “KillUserProcess=yes” in “/etc/systemd/logind.conf” does help for the re-login problem that is discussed here. (By the way that setting fixed it on my system only for about 90%. There are still rare situations a logout/login hangs).
So when I read the above mentioned articles I thought that the announced changes in Plasma 5.21 might address and hopefully fix the current logout/login problem.

37

That is how things should have worked yes, but unfortunatly as i have proven in this topic there are left-over processes.
That’s what the KillUserProcess=yes fixes…

You need to wait about +30s before login again, because that’s about how long it takes for systemd to notice left over processes…

I have no idea what that article you mentioned about writes about, but hopefully you are right and they fix stuff :wink:

But this topic was/is about the current problem and how to fix it while using current KDE/Plasma that is installed with a fresh Manjaro-KDE.

38

Oh, with using “KillUserProcess=yes” still that long? I don’t see this on my system - re-login just needs about 2 seconds.

39

It has to do with the system wide default timeout setting for SystemD’s processes.
IIRC its default is 30s.

40

Because I’m not able to solve your problem, this will be my last post in this thread. I only can add that I tested several Linux distros with latest KDE Plasma the last 2 weeks.

All got the same login/logout problem that could be solved (on my ASUS/Intel based desktop computer) using the “KillUserProcess=yes” setting in “etc/systemd/logind.conf” after fresh install:

Arch Linux with KDE Plasma 20 (Archfi installation - normal and testing mirror)
Manjaro KDE Plasma 19.5/20 (stable/testing and unstable)
EndeavorOS KDE Plasma 19.5/20 (normal and testing mirror)
ArcoLinux KDE Plasma 19.5/20 (normal and testing mirror)
KDE Neon Plasma 19.5/20 (stable and unstable)
Kubuntu 20.10 with KDE Plasma 19.5

So it’s not an exclusive Manjaro KDE problem.

41

Instead of editing /etc/systemd/logind.conf directly, make a config snippet like /etc/systemd/logind.conf.d/override.conf and put your setting there.

1 Like
42

Duh i always reply in that way, how stupid of me not to try it that way :rofl:
:+1: