3

I have two users sessions running. I can switch between users without error most of the time. But after a while, after I try to switch users, on the login screen for the user I am swtiching to, the login screen is frozen solid.

The cursor works on the frozen login screen, but nothing else works. I can not login even if I try to do with without the UI reflecting my typing.

If I hit ctrl+alt+F1, I can switch back and login in to the other user, but if I try to switch to the frozen user, nothing happens.

I am using a Radeon rx580 video card...

Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.11.0-27-generic

Is there, at the very least, a work around to restart or kill that user session without restarting?

6
  • i faced the same issue today morning probably a bug try reporting it with log output to kde support
    – Henzo
    Aug 20, 2021 at 7:15
  • what are dmesg /journalctl saying? if you need to, dig into the logs.
    – Nate T
    Aug 29, 2021 at 18:43
  • Did you get into the TTY? Check the edit to my answer.
    – Nate T
    Aug 30, 2021 at 8:38
  • How much free space do you have? KDE will do this when your hard-drive gets near full. If so, consider it a blessing. : )
    – Nate T
    Aug 30, 2021 at 8:53
  • @NateT I have 67gb free of 227gb.
    – Scorb
    Aug 31, 2021 at 15:20

3 Answers 3

1

Is there at the very least, a work around to restart or kill that user session without restarting?

from a TTY, try running the following:

killall kwin
startkde

This should hopefully restart your user session.

As for the actual fix, we will need to see logs in order to provide this. Most Daemons run on a per-session basis, so it could be literally anything freezing up a session.

EDIT 1

To enter TTY, you just push Ctrl + Alt + F5 (for example) to go to TTY5. Replacing F5 with F6 will take you to TTY6 and so on.

You will be prompted for username and password. Once you are logged in, you should be able to run the commands in both my answer (above) and @SanchoS.ReinstateMonicaCellio 's answer. Hopefully, these will provide you with a workaround.

Next, try running the command

dmesg --facility=daemon

exactly as it is typed here. Just dmesg will work, but this will trim the output to what we likely need. If not, we can circle back and 'widen the net' a bit.

The result will look like a log file. The solution to your issue is likely within those logs. They are in order by date / time (listed for each log), so it should be relatively easy to find the time of the last crash and examine the logs for that time period.

If you need any extra explanation, just let us know. We are happy to explain.

Be sure to post the output of the logs to your question (during the timeframe of the last incident.)

3
  • What is a TTY? Where do I get the logs?
    – Scorb
    Aug 29, 2021 at 19:19
  • Enter tty with [ctrl] + [alt] + [F3].or [F4] up to [F9] I believe. It is an alternate command prompt environment that is handy for situations like yours. logs are in /var/log, but the commands listed in my first comment should display the ones you need.
    – Nate T
    Aug 29, 2021 at 19:40
  • @Scorb Did that help you to get it straightened out?
    – Nate T
    Aug 30, 2021 at 1:34
1

Options to try, assuming user2 is the user for which the session should be restarted

  1. From a terminal (you can access it with Ctrl+Alt+F4 to F6) logged into user2, DISPLAY=:<d> kwin --replace
  2. From a terminal logged into user2, killall -3 kwin && DISPLAY=:<d> kwin
  3. From a terminal logged into user2, kquitapp5 plasmashell && kstart5 plasmashell
  4. From a terminal logged into user2, killall -3 -u user2 (more radical)
  5. From a terminal logged into user1 (has to be sudoer), sudo killall -3 -u user2 (also radical)

Notes:

  1. To find the display number <d> use command who.

  2. The core dump might be useful (compare the various signals, https://stackoverflow.com/questions/4042201/how-does-sigint-relate-to-the-other-termination-signals-such-as-sigterm-sigquit and https://man7.org/linux/man-pages/man7/signal.7.html).

  3. You might expect that this gets solved on its own after the next kernel/kwin update.

  4. If none of the above works, perhaps slight variations/combinations do.

  5. Please post the output of

    $ echo $XDG_SESSION_TYPE
    $ echo $XDG_SESSION_ID
    $ who
    $ ps -efl | grep user2
    
  6. Comparing the output for the cases when user2 is not logged into a kwin session, when it is logged in, and when the session is frozen, is also instructive.

0

Option 3 in the answer https://askubuntu.com/a/1360848/1418851 worked for me in a very similar case. Perhaps this is a comment but i cannot do that because of the reputation, it may be useful for others to know.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.