Màn hình đăng nhập Kubfox bị đóng băng khi chuyển đổi người dùng

Tôi có hai phiên người dùng đang chạy. Tôi có thể chuyển đổi giữa những người dùng mà không gặp lỗi trong hầu hết thời gian. Nhưng sau một thời gian, sau khi tôi cố gắng chuyển đổi người dùng, trên màn hình đăng nhập cho người dùng mà tôi đang chuyển đổi, màn hình đăng nhập bị đóng băng.

Con trỏ hoạt động trên màn hình đăng nhập bị đóng băng, nhưng không có gì khác hoạt động. Tôi không thể đăng nhập ngay cả khi tôi cố gắng thực hiện mà không có giao diện người dùng phản ánh cách nhập của tôi.

Nếu tôi nhấn ctrl+alt+F1, tôi có thể quay lại và đăng nhập với người dùng khác, nhưng nếu tôi cố gắng chuyển sang người dùng bị đóng băng thì không có gì xảy ra.

Tôi đang sử dụng card màn hình Radeon rx580 ...

Hệ điều hành: Kubfox 20.04 Phiên bản KDE Plasma: 5.18.5 Phiên bản khung KDE: 5.68.0 Phiên bản Qt: 5.12.8 Phiên bản hạt nhân: 5.11.0-27-chung

Ít nhất, có cách nào để khởi động lại hoặc hủy phiên người dùng đó mà không cần khởi động lại không?

Có ít nhất, một công việc xung quanh để khởi động lại hoặc hủy phiên người dùng đó mà không cần khởi động lại không?

từ TTY, hãy thử chạy như sau:

giết tất cả kwin
bắt đầu

Điều này hy vọng sẽ khởi động lại phiên người dùng của bạn.

Đối với bản sửa lỗi thực tế, chúng tôi sẽ cần xem nhật ký để cung cấp bản sửa lỗi này. Hầu hết các Daemon chạy trên cơ sở mỗi phiên, vì vậy nó có thể là bất cứ thứ gì đóng băng một phiên theo đúng nghĩa đen.

CHỈNH SỬA 1

Để vào TTY, bạn chỉ cần nhấn Điều khiển + thay thế + F5 (ví dụ) để chuyển đến TTY5. thay thế F5 với F6 sẽ đưa bạn đến TTY6, v.v.

Bạn sẽ được nhắc nhở nhập tên người dùng và mật khẩu. Khi bạn đã đăng nhập, bạn sẽ có thể chạy các lệnh trong cả câu trả lời của tôi (ở trên) và câu trả lời của @SanchoS.ReinstateMonicaCellio. Hy vọng, những điều này sẽ cung cấp cho bạn một cách giải quyết.

Tiếp theo, hãy thử chạy lệnh

dmesg --facility=daemon

chính xác như nó được gõ ở đây. Chỉ cần dmesg sẽ hoạt động, nhưng điều này sẽ cắt đầu ra thành những gì chúng ta có thể cần. Nếu không, chúng ta có thể vòng lại và 'mở rộng mạng lưới' một chút.

Kết quả sẽ giống như một tệp nhật ký. Giải pháp cho vấn đề của bạn có thể nằm trong các nhật ký đó. Chúng được sắp xếp theo thứ tự ngày/giờ (được liệt kê cho mỗi nhật ký), vì vậy sẽ tương đối dễ dàng tìm thấy thời điểm xảy ra sự cố cuối cùng và kiểm tra nhật ký trong khoảng thời gian đó.

Nếu bạn cần thêm bất kỳ lời giải thích nào, chỉ cần cho chúng tôi biết. Chúng tôi rất vui được giải thích.

Đảm bảo đăng đầu ra của nhật ký cho câu hỏi của bạn (trong khung thời gian của sự cố cuối cùng.)

Tùy chọn để thử, giả sử người dùng2 là người dùng mà phiên sẽ được khởi động lại

1. Từ một thiết bị đầu cuối (bạn có thể truy cập nó bằng Điều khiển+thay thế+F4 đến F6) đăng nhập vào người dùng2, HIỂN THỊ=:<d> kwin --replace
2. Từ một thiết bị đầu cuối đăng nhập vào người dùng2, killall -3 kwin && HIỂN THỊ=:<d> kwin
3. Từ một thiết bị đầu cuối đăng nhập vào người dùng2, kquitapp5 plasmashell && kstart5 plasmashell
4. Từ một thiết bị đầu cuối đăng nhập vào người dùng2, killall -3 -u user2 (cực đoan hơn)
5. Từ một thiết bị đầu cuối đăng nhập vào người dùng1 (phải là sudoer), sudo killall -3 -u user2 (cũng cấp tiến)

ghi chú:

1. Để tìm số hiển thị <d> sử dụng lệnh Ai.

2. bãi rác cốt lõi có thể hữu ích (so sánh các tín hiệu khác nhau, https://stackoverflow.com/questions/4042201/how-does-sigint-relate-to-the-other-termination-signals-such-as-sigterm-sigquit và https://man7.org/linux/man-pages/man7/signal.7.html).

3. Bạn có thể mong đợi rằng vấn đề này sẽ tự được giải quyết sau lần cập nhật kernel/kwin tiếp theo.

4. Nếu không có cách nào ở trên hoạt động, có lẽ các biến thể/kết hợp nhỏ sẽ làm được.

5. Vui lòng đăng đầu ra của

   $ tiếng vang $XDG_SESSION_TYPE
   $ tiếng vang $XDG_SESSION_ID
   $ ai
   $ps-efl | người dùng grep2
   

6. So sánh đầu ra cho các trường hợp khi người dùng2 không được đăng nhập vào phiên kwin, khi nó được đăng nhập và khi phiên bị đóng băng, cũng mang tính hướng dẫn.

Lựa chọn 3 trong câu trả lời https://askubuntu.com/a/1360848/1418851 làm việc cho tôi trong một trường hợp rất giống nhau. Có lẽ đây là một nhận xét nhưng tôi không thể làm điều đó vì danh tiếng, nó có thể hữu ích cho những người khác biết.