Ecranul de conectare Kubuntu este înghețat la schimbarea utilizatorilor

Am două sesiuni de utilizatori care rulează. Pot comuta între utilizatori fără erori de cele mai multe ori. Dar după un timp, după ce încerc să schimb utilizatorii, pe ecranul de autentificare pentru utilizatorul la care mă schimb, ecranul de autentificare este înghețat.

Cursorul funcționează pe ecranul de conectare înghețat, dar nimic altceva nu funcționează. Nu mă pot autentifica chiar dacă încerc să fac fără ca interfața de utilizare să reflecte tastarea mea.

Dacă apes ctrl+alt+F1, pot comuta înapoi și mă pot autentifica la celălalt utilizator, dar dacă încerc să trec la utilizatorul înghețat, nu se întâmplă nimic.

Folosesc o placa video Radeon rx580...

Sistem de operare: Kubuntu 20.04 Versiunea KDE Plasma: 5.18.5 Versiunea KDE Frameworks: 5.68.0 Versiunea Qt: 5.12.8 Versiunea Kernel: 5.11.0-27-generic

Există, cel puțin, o soluție pentru a reporni sau a opri acea sesiune de utilizator fără a reporni?

Există cel puțin o soluție pentru a reporni sau a opri acea sesiune de utilizator fără a reporni?

de la un TTY, încercați să rulați următoarele:

killall kwin
startkde

Acest lucru ar trebui să repornească sesiunea dvs. de utilizator.

În ceea ce privește remedierea reală, va trebui să vedem jurnalele pentru a oferi acest lucru. Majoritatea Daemon-urilor rulează pe sesiune, așa că ar putea fi literalmente orice care blochează o sesiune.

EDITARE 1

Pentru a introduce TTY, trebuie doar să apăsați Ctrl + Alt + F5 (de exemplu) pentru a merge la TTY5. Înlocuirea F5 cu F6 vă va duce la TTY6 și așa mai departe.

Vi se va solicita numele de utilizator și parola. Odată ce v-ați conectat, ar trebui să puteți rula comenzile atât din răspunsul meu (mai sus), cât și din răspunsul lui @SanchoS.ReinstateMonicaCellio. Sperăm că acestea vă vor oferi o soluție.

Apoi, încercați să rulați comanda

dmesg --facility=daemon

exact așa cum este scris aici. Doar dmesg va funcționa, dar acest lucru va reduce rezultatul la ceea ce probabil avem nevoie. Dacă nu, putem să ne întoarcem și să „largim plasa” puțin.

Rezultatul va arăta ca un fișier jurnal. Soluția la problema dvs. se află probabil în acele jurnale. Acestea sunt în ordine în funcție de dată / oră (afișate pentru fiecare jurnal), așa că ar trebui să fie relativ ușor să găsiți ora ultimei blocări și să examinați jurnalele pentru acea perioadă de timp.

Dacă aveți nevoie de vreo explicație suplimentară, anunțați-ne. Suntem bucuroși să explicăm.

Asigurați-vă că postați rezultatul jurnalelor la întrebarea dvs. (în timpul ultimului incident.)

Opțiuni de încercat, presupunând utilizator2 este utilizatorul pentru care ar trebui repornită sesiunea

1. Dintr-un terminal (îl poți accesa cu Ctrl+Alt+F4 la F6) conectat utilizator2, DISPLAY=:<d> kwin --inlocuire
2. De la un terminal conectat utilizator2, killall -3 kwin && DISPLAY=:<d> kwin
3. De la un terminal conectat utilizator2, kquitapp5 plasmashell && kstart5 plasmashell
4. De la un terminal conectat utilizator2, killall -3 -u user2 (mai radical)
5. De la un terminal conectat utilizator1 (trebuie să fie sudoer), sudo killall -3 -u user2 (de asemenea radical)

Note:

1. Pentru a găsi numărul de afișare <d> utilizați comanda OMS.

2. Halda de miez ar putea să fie util (comparați diferitele semnale, https://stackoverflow.com/questions/4042201/how-does-sigint-relate-to-the-other-termination-signals-such-as-sigterm-sigquit și https://man7.org/linux/man-pages/man7/signal.7.html).

3. Vă puteți aștepta ca acest lucru să fie rezolvat de la sine după următoarea actualizare a kernelului/kwin.

4. Dacă niciuna dintre cele de mai sus nu funcționează, poate ușoare variații/combinații funcționează.

5. Vă rugăm să postați rezultatul

   $ echo $XDG_SESSION_TYPE
   $ echo $XDG_SESSION_ID
   $ cine
   $ ps -efl | utilizator grep2
   

6. Compararea rezultatelor pentru cazurile în care utilizator2 nu este conectat la o sesiune kwin, atunci când este autentificat și când sesiunea este înghețată, este, de asemenea, instructiv.

Opțiunea 3 din răspuns https://askubuntu.com/a/1360848/1418851 a lucrat pentru mine într-un caz foarte asemănător. Poate că acesta este un comentariu, dar nu pot face asta din cauza reputației, poate fi util pentru alții să știe.