I've been having this problem for over 4 years, through various distro upgrades, on 2 different PCs, and have just been living with it since it's my work computer & I rarely log out or reboot it. But... Whenever I logout/shutdown/reboot a KDE session, it appears to go nicely for a while, then the system hangs. Like, NO keyboard/mouse response at all; can't even drop to a console. The only solution at that point is a power cycle. I've tried various methods like logging out & immediately switching to another VT, but it still freezes eventually. Tried killing my session from a VT by killing the session, still hangs. Tried Ctrl-Shift-Backspace to kill the X session; still ends up hanging. I used to be able to force a reboot with the "magic" SysRq keys, but as of Kubuntu 16.04.1 even that doesn't seem to work any more. Any suggestions on what log files I can examine or debug output I can enable to figure out what the culprit is?
Additional: *Sometimes* logout/shutdown/reboot works OK... typically if I've just logged in, but not always. I have a suspicion that it's not actually KDE winding down, but rather the DM (using lightdm, but I've tried others) or the X server itself hanging on restart.
The KDE bug tracker is not a support or help forum. I suggest to post your issue to your distribution's forum.
I have seen this problem in the Fedora packages as well. The effects on user experience are quite severe rendering KDE not usable in a lab environment as an example. What can be done to get someone @ KDE to look at this ?
What version of Plasma are you still seeing this with?
(In reply to Nate Graham from comment #4) > What version of Plasma are you still seeing this with? [pdubois@Blackcat ~]$ rpm -qa |grep plasma plasma-nm-openvpn-5.18.5-1.fc32.x86_64 plasma-workspace-5.18.5-2.fc32.x86_64 plasma-pa-5.18.5-1.fc32.x86_64 plasma-workspace-common-5.18.5-2.fc32.x86_64 plasma-nm-pptp-5.18.5-1.fc32.x86_64 plasma-integration-5.18.5-2.fc32.x86_64 plasma-drkonqi-5.18.5-1.fc32.x86_64 plasma-discover-5.18.5-1.fc32.x86_64 plasma-user-manager-5.18.5-1.fc32.x86_64 plasma-milou-5.18.5-1.fc32.x86_64 plasma-nm-openconnect-5.18.5-1.fc32.x86_64 plasma-nm-5.18.5-1.fc32.x86_64 plasma-lookandfeel-fedora-5.18.5-2.fc32.noarch plasma-pk-updates-0.3.2-7.fc32.x86_64 plasma-breeze-common-5.18.5-1.fc32.noarch kde-settings-plasma-32.0-3.fc32.noarch plasma-nm-vpnc-5.18.5-1.fc32.x86_64 plasma-nm-openswan-5.18.5-1.fc32.x86_64 kf5-plasma-5.70.1-1.fc32.x86_64 plasma-workspace-geolocation-libs-5.18.5-2.fc32.x86_64 plasma-desktop-doc-5.18.5-2.fc32.noarch plasma-systemsettings-5.18.5-1.fc32.x86_64 plasma-nm-l2tp-5.18.5-1.fc32.x86_64 plasma-workspace-libs-5.18.5-2.fc32.x86_64 plasma-discover-flatpak-5.18.5-1.fc32.x86_64 plasma-discover-libs-5.18.5-1.fc32.x86_64 kdeplasma-addons-5.18.5-1.fc32.x86_64 plasma-browser-integration-5.18.5-1.fc32.x86_64 plasma-workspace-geolocation-5.18.5-2.fc32.x86_64 plasma-breeze-5.18.5-1.fc32.x86_64 plasma-desktop-5.18.5-2.fc32.x86_64
5.18.5. Thanks.
Created attachment 131579 [details] output from lshw Hardware list as mentioned.
*** Bug 424297 has been marked as a duplicate of this bug. ***
I do confirm this for an LFS-8.2/-10.1 -system. For me it started with 5.19.5 (qt5-15.1/fw-5.75). It's still there in 5.20.5 and 5.21.4 (qt5-15.2/fw-5.81). In 5.20.5 it happens with X-sessions and Wayland-sessions, I haven't tried Wayland in other versions. Plasma <= 5.17.5 is not affected. Neither is xfce-14/-16. It only happens after having used the system for a while. That's the only pattern I could make out so far. A logout following relatively shortly after a login does work. Resuming from standby or hibernate is also no problem, Plasma is otherwise stable. Trying to replace the session with DISPLAY=:0 kwin_x11 --replace doesn't work. Only killing startplasma-x11/-wayland brings back the login-box (Lightdm) immediately. Else a reboot would be necessary. To me it seems that under certain circumstances startplasma-x11 is not being terminated during logout/reboot etc. It's probably not the settings in .config, .kde or .local as I've started with brand new ones and still saw it after a while and after some of the usual adaptations. System- and X-logs don't offer any insight for me. They look pretty normal. Any ideas how to approach this are welcome.
(In reply to Christoph Feck from comment #2) > The KDE bug tracker is not a support or help forum. I suggest to post your > issue to your distribution's forum. And I suggest you take KDE-users/-supporters seriously.
Interesting update : After having migrated my workstation to F34 I continued to have the logout issue. as mentioned above. I wiped all KDE related configuration as well as any other desktop related display configs such as that for gnnome applications. The problem persisted. I was starting to suspect the commercial Nvidia drivers. There was a recent F34 update for KF5 and after a reboot the problem appears to have resolved. I have not had a single logout lockup since this update.
>And I suggest you take KDE-users/-supporters seriously. We will, but only once you can indicate that KDE is at fault. If the mouse cursor stops, that means X11 is frozen. That's lower in the stack.
In my experience the lockups resulted in a cursor that moved as expected. A restart of the SDDM service would bring back the login page.
(In reply to David Edmundson from comment #12) > >And I suggest you take KDE-users/-supporters seriously. > > We will, but only once you can indicate that KDE is at fault. > And otherwise you don't take us seriously? But I bet, you want us to take *you* seriously, right? Interesting attitude. > If the mouse cursor stops, that means X11 is frozen. That's lower in the > stack. In my case the cursor *does* move after the desktop freezes. At times I even had a blinking cursor in LibreOffice when everything else was dead. I don't have a black screen, though - all windows are still there, just frozen. The graphics-driver is Intel. And how would you explain that versions <= 5.17.5 and also xfce (same box) are *not* affected?
>And otherwise you don't take us seriously? That's not the terminology I would have chosen, there wouldn't be anything for us to do. It sounds like you have completely different issue to the issue in #1. So lets use this bug for that and start anew in a hopefully more productive way. The mouse moves - so x11 is not frozen Libreoffice updates, so client buffers update - therefore we also know kwin is not frozen (assuming compositing is on) "all windows are still there, just frozen." - what does this entail? Can you click the close icon? Can you VT switch? If so can you verify the processes are running? can you gdb into kwin?
There may be some misunderstanding of how this bug presents. Often, and over several versions of distributions and versions of KDE the logout lockup would usually present on my systems as black screens with a moving cursor. It would also sometimes lock up with no cursor present. Getting the system to return to a login prompt would traditionally require killing all user specific KDE processes. More recently, user processes would exit leaving no user specific session or processes. In this case, a restart of the SDDM service returned the workstation to a login prompt. With fedora in any case, this appears resolved for me after a recent update of the Fedora KDE KF5 packages.
(In reply to Patrick Dubois from comment #16) > There may be some misunderstanding of how this bug presents. > > Often, and over several versions of distributions and versions of KDE the > logout lockup would usually present on my systems as black screens with a > moving cursor. > > It would also sometimes lock up with no cursor present. > > Getting the system to return to a login prompt would traditionally require > killing all user specific KDE processes. More recently, user processes > would exit leaving no user specific session or processes. In this case, a > restart of the SDDM service returned the workstation to a login prompt. > > With fedora in any case, this appears resolved for me after a recent update > of the Fedora KDE KF5 packages. For me it's still: login, logout, lockup. ;) Can you tell us the Frameworks-version that the recent Fedora-update provided? Thanks.
(In reply to David Edmundson from comment #15) > >And otherwise you don't take us seriously? > > That's not the terminology I would have chosen, there wouldn't be anything > for us to do. > > It sounds like you have completely different issue to the issue in #1. So > lets use this bug for that and start anew in a hopefully more productive way. Up to you. The OP's approach and mine *were* productive. It was the reaction(s) that were not. It takes time and effort and also courage to write a bug-report and expose oneself. You should be thankful for every single one you get. Even if it later turns out that it was perhaps not spot-on. Because at least it offers you a chance to improve your stuff. Or to foster user-(customer-) relations. By arrogantly wiping things off the table, the opposite is achieved. And personally, I'm rather fed up with this behaviour. > > The mouse moves - so x11 is not frozen > > Libreoffice updates, so client buffers update - therefore we also know kwin > is not frozen (assuming compositing is on) > > "all windows are still there, just frozen." - what does this entail? > That all windows of all apps are frozen? > Can you click the close icon? Yes - but to no avail. > Can you VT switch? If so can you verify the processes are running? can you > gdb into kwin? Yes, I can switch to a VT and I can see the processes. As far as I can tell, all the Plasma-associated p's are still there. What brings me back to the login-box is killing startplasma-x11. I'm not sure whether I can gdb into kwin. At least not within the next few days.
My current KF5 version appears to be 5.82.0-1 and 5.82.0-2 depending on the specific framework package.
(In reply to Patrick Dubois from comment #19) > My current KF5 version appears to be 5.82.0-1 and 5.82.0-2 depending on the > specific framework package. Thanks. I had built Plasma-5.20/21 with FW-5.81.0. So perhaps FW-5.82.0 brings a fix for the problem. I'll give it a try and report back.
Ok, please report back with that frameworks version, but I can't off-hand think of anything. If you do manage to gdb into kwin (sudo gdb --pid `pidof kwin_x11`) please type "set logging on" "bt" it will create a file called gdb.txt that will indicate It would also be useful to know if aggressively killing kwin_x11 helps unlock the situation.
Created attachment 138798 [details] gdb backtrace for kwin-x11
Created attachment 138799 [details] gdb backtrace for kwin-x11, all threads
(In reply to David Edmundson from comment #21) > Ok, please report back with that frameworks version, but I can't off-hand > think of anything. So I will postpone that. Building gdb was much faster anyway. > > If you do manage to gdb into kwin > (sudo gdb --pid `pidof kwin_x11`) > > please type > "set logging on" > "bt" > > it will create a file called gdb.txt that will indicate > > It would also be useful to know if aggressively killing kwin_x11 helps > unlock the situation. Thanks. What I did: - switch to a VT > ps -e | grep kwin > gdb --pid=8756 |& tee gdb_kwin.txt > detach > quit > gdb --pid=8756 |& tee gdb_kwin_all_threads.txt > thread apply all backtrace > detach > quit I hope this is OK and helps. Both files are attached. Aggressively killing kwin (kill -9 pid_kwin) never helped. It had to be "kill startplasma-x11". Could this have something to do with OpenGL?
Thanks. Backtrace shows kwin isn't frozen. It's happily polling as expected. The fact that killing it didn't fix anything also implies kwin isn't at fault. One other possibility is that nothing is frozen, and something has an input grab: DISPLAY=:0 xdotool key "XF86LogGrabInfo" from a TTY should hopefully show that.
(In reply to David Edmundson from comment #25) > Thanks. > > Backtrace shows kwin isn't frozen. It's happily polling as expected. > The fact that killing it didn't fix anything also implies kwin isn't at > fault. > > One other possibility is that nothing is frozen, and something has an input > grab: > DISPLAY=:0 xdotool key "XF86LogGrabInfo" > > from a TTY should hopefully show that. Perhaps a misunderstanding on my side. I took those backtraces when kwin was *not* hung. Shortly thereafter it did hang. Here's an excerpt from the backtrace: [...] [?2004h(gdb) thread apply all backtrace [?2004l Thread 11 (LWP 10570 "FreezeDetector"): #0 0x00007fd0bc9778c6 in __ppoll (fds=0x7fd084075f28, nfds=1, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:48 #1 0x00007fd0bd1e6679 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () from /opt/qt5/lib/libQt5Core.so.5 #2 0x00007fd0bd1e7b53 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /opt/qt5/lib/libQt5Core.so.5 #3 0x00007fd0bd194f3b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /opt/qt5/lib/libQt5Core.so.5 #4 0x00007fd0bcfb843e in QThread::exec() () from /opt/qt5/lib/libQt5Core.so.5 #5 0x00007fd0bcfb9451 in ?? () from /opt/qt5/lib/libQt5Core.so.5 #6 0x00007fd0be3f7d5e in start_thread (arg=0x7fd08ec03640) at pthread_create.c:473 #7 0x00007fd0bc98220f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 10 (LWP 9600 "QSGRenderThread"): [...] It also happened with XRender. Full backtrace attached.
Created attachment 138801 [details] gdb_kwin_hung_all_threads
OK, here's the feedback regarding FW-5.82.0: it didn't help. Rather seemed to make things worse because logout didn't work anymore, even when done shortly after a login and only a few apps were running. Logout was OK when no apps were running. I then thought that I had nailed it by stopping and de-activating background-service "GNOME/GTK Settings Synchronization Service" because logout then worked even with many apps running and was much faster than before. But when leaving the desktop alone for a few minutes and then logging out, the problem resurfaced. What I noticed was that after switching to a VT and "ps -e | grep plasm" there was "plasma-shutdown" in the list. But when issuing the command again after a short while "plasma-shutdown" was gone. Don't know if this is of any significance. Anyway, this weird thing remains a mystery to me.
I assume you are using SDDM ? Have you tried switching to a VT and restarting the SDDM service ?
(In reply to Patrick Dubois from comment #29) > I assume you are using SDDM ? Have you tried switching to a VT and > restarting the SDDM service ? I'm using lightdm which works as it should. The problem is elsewhere. What I can say now is that Plasma-5.18 also does work here. The logouts take longer than with 5.17 but in the end they succeed. So I guess that our logout-problem has a different cause. That's probably why the update to FW-5.82.0 solved yours but not mine. I suspect changes in the code for shutdown between 5.18 and 5.19 to be responsible for the freezes/hangs in my case. Seems, they are not compatible with my system-V-system. IMO there's no other explanation. Thanks for your thoughts!
Once logged in, there is a process "plasma_session" in Plasma < 5.19 whereas there is no such process in Plasma >= 5.19 (on my systems). Is it normal for Plasma >= 5.19 that this process is not running? Or may this be the root-cause for my logout-problems? Thanks.
Is there a git-repo for "plasma-workspace" that I could clone? I could then try to bisect this between 5.18 and 5.19. Thanks.
Yep: git@invent.kde.org:plasma/plasma-workspace.git
(In reply to Nate Graham from comment #33) > Yep: git@invent.kde.org:plasma/plasma-workspace.git Thanks. This worked for me: git clone https://invent.kde.org/plasma/plasma-workspace.git Bisecting will take a while. I hope that something useful comes out of it.
OK, I bisected between 5.18.7 (good) and 5.19.0 (bad). Base-system was Plasma-5.18.7. "Good" was when the logout completed within 2 min after klicking on "Logout", "bad" when not and the desktop did not respond to keyboard or mouse anymore. FWIW, here's the result (also see the bisect-log below): b2df03a51f979066e6b0211dfd4986c2d1820089 is the first bad commit commit b2df03a51f979066e6b0211dfd4986c2d1820089 Author: Bart Ribbers <bribbers@disroot.org> Date: Mon Mar 2 14:10:53 2020 +0100 [Language KCM] Wrap the label text Summary: This way the text doesn't get cut off the screen on at least the PinePhone Test Plan: 1. Open the Language KCM on a small screen without this patch 2. Open the Language KCM on a small screen with this patch Reviewers: davidedmundson Reviewed By: davidedmundson Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D27781 kcms/translations/package/contents/ui/main.qml | 1 + 1 file changed, 1 insertion(+) Don't know whether that makes sense but this it what came out of it. Thanks. *** # bad: [2e631affa3bcb14a4aeb91647e350126be42d488] Update version number for 5.19.0 GIT_SILENT # good: [fc52a24803858d254d4dc5b2ad5b3502d6758c89] Update version number for 5.18.7 GIT_SILENT git bisect start 'v5.19.0' 'v5.18.7' # good: [d71181245f138f45da2760e85fdb6c38b785c0d9] [Notifications] Don't take updated time into account for sorting git bisect good d71181245f138f45da2760e85fdb6c38b785c0d9 # bad: [9be7dedb87ea574916f0f8a2837eaf7b19a7a166] Use new simpler way to disable session management in services git bisect bad 9be7dedb87ea574916f0f8a2837eaf7b19a7a166 # good: [aa3319e2a97be50f49990c709929fbe14e889e0d] Merge branch 'Plasma/5.18' git bisect good aa3319e2a97be50f49990c709929fbe14e889e0d # bad: [2130c848e677d491687ee49f28b07a2ee6f8b7c7] [applet/digital-clock] Show time zones in expanded representation too git bisect bad 2130c848e677d491687ee49f28b07a2ee6f8b7c7 # good: [9e0711ac408dc16f10f126f41b286e3f72ff1e94] Make the icon hitboxes for the System Tray Plasmoid larger when Kirigami Tablet Mode is enabled git bisect good 9e0711ac408dc16f10f126f41b286e3f72ff1e94 # bad: [149075077b821935211794424bd8c8f1fcca5049] Changed leftMargins to smallSpacing to be consistent git bisect bad 149075077b821935211794424bd8c8f1fcca5049 # bad: [b2df03a51f979066e6b0211dfd4986c2d1820089] [Language KCM] Wrap the label text git bisect bad b2df03a51f979066e6b0211dfd4986c2d1820089 # good: [ff84d313592e84b6d77307a568575fe782f0e9d8] SVN_SILENT made messages (.desktop file) - always resolve ours git bisect good ff84d313592e84b6d77307a568575fe782f0e9d8 # good: [3c34dfa97f3ed5ba1c28a02e85c4de73877469fb] [plasma-session] Load startup and shutdown on demand git bisect good 3c34dfa97f3ed5ba1c28a02e85c4de73877469fb # first bad commit: [b2df03a51f979066e6b0211dfd4986c2d1820089] [Language KCM] Wrap the label text
That can't possibly be the offending commit as it is a UI bugfix for an unrelated piece of code (the language KCM) which has no way of touching the logout/shutdown/reboot process.
(In reply to Nate Graham from comment #36) > That can't possibly be the offending commit as it is a UI bugfix for an > unrelated piece of code (the language KCM) which has no way of touching the > logout/shutdown/reboot process. Almost thought so. The problem is to find a truly reliable trigger for this thing. The best that I could find was to load many programs (a defined set of) and then log out. But in some cases that may not have been enough to provoke the hang. So it may be that one or the other of the "goods" was a false negative which would then invalidate the final result. The "bads" were clearly bads - that's for sure. What's also puzzling for me is that some logouts happen really fast while others take really long but in the end succeed (hence the 2 minutes wait). When I'm sure I have a definitely trusty trigger I might repeat the bisect.
Re-testet the last step with more load and time and it was indeed a false negative, logout failed. Assuming (!) that otherwise all "goods" were correct the final result then would be: 3c34dfa97f3ed5ba1c28a02e85c4de73877469fb is the first bad commit commit 3c34dfa97f3ed5ba1c28a02e85c4de73877469fb Author: David Edmundson <kde@davidedmundson.co.uk> Date: Mon Mar 2 13:05:35 2020 +0000 [plasma-session] Load startup and shutdown on demand Summary: Currently startplasma spawns plasma-session then sits around waiting for that to finish plasma-session spawns all the startup then also just sits around doing nothing This patch makes plasma-session spawn all the startup and then quit. It also splits the owner of the org.kde.shutdown interface to be on demand. plasma-shutdown asks ksmserver to quit and then if applicable runs the shutdown scripts or not. Startplasma then knows when to exit by monitoring the DBus service status directly. The benefits are that we save some resources by not needing plasma-session lingering about. It also means the shutdown interface is re-usable as-is when the pending systemd startup method is used. Test Plan: Logged in and: - ran killall ksmserver, session ended as before - logged out and cancelled due to unsaved changes - logged out and completed logout - logged out and rebooted Reviewers: #plasma, apol Reviewed By: apol Subscribers: apol, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D27629 ksmserver/CMakeLists.txt | 2 +- libkworkspace/CMakeLists.txt | 2 +- startkde/CMakeLists.txt | 1 + startkde/plasma-session/CMakeLists.txt | 3 - startkde/plasma-session/main.cpp | 3 - startkde/plasma-session/org.kde.Shutdown.xml | 8 --- startkde/plasma-session/shutdown.cpp | 97 -------------------------- startkde/plasma-session/shutdown.h | 45 ------------ startkde/plasma-session/startup.cpp | 1 + startkde/plasma-shutdown/CMakeLists.txt | 23 +++++++ startkde/plasma-shutdown/main.cpp | 28 ++++++++ startkde/plasma-shutdown/org.kde.Shutdown.xml | 8 +++ startkde/plasma-shutdown/shutdown.cpp | 99 +++++++++++++++++++++++++++ startkde/plasma-shutdown/shutdown.h | 45 ++++++++++++ startkde/startplasma-wayland.cpp | 1 + startkde/startplasma-x11.cpp | 4 +- startkde/startplasma.cpp | 45 ++++++++++-- 17 files changed, 249 insertions(+), 166 deletions(-) delete mode 100644 startkde/plasma-session/org.kde.Shutdown.xml delete mode 100644 startkde/plasma-session/shutdown.cpp delete mode 100644 startkde/plasma-session/shutdown.h create mode 100644 startkde/plasma-shutdown/CMakeLists.txt create mode 100644 startkde/plasma-shutdown/main.cpp create mode 100644 startkde/plasma-shutdown/org.kde.Shutdown.xml create mode 100644 startkde/plasma-shutdown/shutdown.cpp create mode 100644 startkde/plasma-shutdown/shutdown.h At first glance this makes more sense than the one reported previously. When I find time I'll re-test the other "goods".
That looks far more likely. :)
OK, re-testet the other goods the way I tested the last (false) good yesterday and they were all good indeed. This confirms yesterday's result: 3c34dfa97f3ed5ba1c28a02e85c4de73877469fb is the first bad commit commit 3c34dfa97f3ed5ba1c28a02e85c4de73877469fb Author: David Edmundson <kde@davidedmundson.co.uk> Date: Mon Mar 2 13:05:35 2020 +0000 [plasma-session] Load startup and shutdown on demand [...] What now?
Somebody needs to investigate. :) That's a huge commit, so it's not exactly a simple task.
(In reply to Nate Graham from comment #41) > Somebody needs to investigate. :) So I hope you'll find one. ;) > > That's a huge commit, so it's not exactly a simple task. Perhaps only the shutdown-part needs a little tweaking. All else is fine.
As it seems, the program "Ding" (a dictionary) may be involved somehow. So far all logouts under 5.21.4 and 5.20.5 succeeded when Ding was not running. Ding uses tcl/tk and runs in a process named "wish". I became aware of Ding's potential role in this matter when I wanted to manually save a session in 5.18.7: the moment I clicked on "Logout", Ding's icon in the taskbar vanished and the desktop hung. That was practically identical to what I have already reported for versions >5.18 with automatically saved sessions. I then tried to manually save a session whithout Ding running and that succeeded. Automatically saved sessions always succeed in 5.18.7, irrespective of Ding running or not. Ding was always on autostart, so it was running whenever I experienced a freeze on logout in versions > 5.18. After updating Ding to the latest version (1.9) I startet it under Plasma-5.20.5 and logged out which was OK. On a second try and after using the PC for a while, however, the desktop hung as already described. I checked for process "wish" but that had obviously been terminated. I then had to kill "startplasma-x11" to be able to log into Plasma again. After a while a crash-report came up. There was a hint that said that the information gathered is probably useless but I attached it anyway.
Created attachment 141264 [details] Crash-report after a hung session
If this info helps with figuring this one out: I am also experiencing the freeze on logout problem. I've been using fedora/KDE for about 10 years now and never experienced this problem before. Here's my info: 1. In mid November I did a clean install of fedora 35, KDE spin (coming from f-32/KDE - but a clean install, not fedup). I took all the defaults. So that means I started on Wayland. 2. I did a user logout, from Wayland, and it worked perfectly. 3. Ever since that 1st time it has never worked. Not on Wayland and also not when I switch over to X11. 4. Scenario-A: From the Applications menu, select 'logout' from that lower-right section of the favourites panel. I then get the normal screen that has the logout options on it (i.e., Shutdown, Logout, Restart, etc - is that what folks refer to as SSDM?). The Logout option is defaulted with the usual countdown timer running. When I click on the ‘Logout’ icon to override the timer and logout immediately the screen simply freezes there. The counter stops, none of the other buttons are active, keyboard has no effect, etc. Tho I can still move the mouse pointer around, but clicking on anything has no effect whatsoever. I've never been able to stumble across any set of keystrokes that causes anything to happen. Just frozen. When I then press my PC’s power button it shuts off immediately, no hesitation (suggesting that fedora/KDE has actually logged out and shut down the user session?, it just isn’t showing me the screen to re-login...maybe?). 5. Scenario-B. Select logout from the Application menu as before; get that normal logout screen, but this time let the countdown timer finish - never touch the mouse or keyboard. In this scenario all is well, the login screen appears and I can login back in with no issue. 6. Scenario-C. Instead of seletecting logout, select 'Restart.' In this case it works just fine. Same for 'Shutdown.' 7. Scenario-D. Create a new user. For this new user login/logout works just fine. However, in testing this I haven't had this test user logged in for more that 10 minutes; and I just tried doing this today. So this may not be a good test-case given imaginator's description in comment #9. I am running an Intel desktop PC; pure Intel graphics, no 3rd-part graphics card installed. Dual 4K monitors, if that matters. Specifics below: Operating System: Fedora Linux 35 KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 Kernel Version: 5.15.11-200.fc35.x86_64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 I'd be great to have this oddity fixed. Much appreciation for all that you all do to maintain KDE. Not sure I'd using Linux were it not for KDE.
(In reply to Jeffrey Rocchio from comment #45) > If this info helps with figuring this one out: > > I am also experiencing the freeze on logout problem. I've been using > fedora/KDE for about 10 years now and never experienced this problem before. > > Here's my info: > > 1. In mid November I did a clean install of fedora 35, KDE spin (coming from > f-32/KDE - but a clean install, not fedup). I took all the defaults. So that > means I started on Wayland. > > 2. I did a user logout, from Wayland, and it worked perfectly. > > 3. Ever since that 1st time it has never worked. Not on Wayland and also not > when I switch over to X11. > > 4. Scenario-A: From the Applications menu, select 'logout' from that > lower-right section of the favourites panel. I then get the normal screen > that has the logout options on it (i.e., Shutdown, Logout, Restart, etc - is > that what folks refer to as SSDM?). The Logout option is defaulted with the > usual countdown timer running. When I click on the ‘Logout’ icon to override > the timer and logout immediately the screen simply freezes there. The > counter stops, none of the other buttons are active, keyboard has no effect, > etc. Tho I can still move the mouse pointer around, but clicking on anything > has no effect whatsoever. I've never been able to stumble across any set of > keystrokes that causes anything to happen. Just frozen. When I then press my > PC’s power button it shuts off immediately, no hesitation (suggesting that > fedora/KDE has actually logged out and shut down the user session?, it just > isn’t showing me the screen to re-login...maybe?). > > 5. Scenario-B. Select logout from the Application menu as before; get that > normal logout screen, but this time let the countdown timer finish - never > touch the mouse or keyboard. In this scenario all is well, the login screen > appears and I can login back in with no issue. > > 6. Scenario-C. Instead of seletecting logout, select 'Restart.' In this case > it works just fine. Same for 'Shutdown.' > > 7. Scenario-D. Create a new user. For this new user login/logout works just > fine. However, in testing this I haven't had this test user logged in for > more that 10 minutes; and I just tried doing this today. So this may not be > a good test-case given imaginator's description in comment #9. > > I am running an Intel desktop PC; pure Intel graphics, no 3rd-part graphics > card installed. Dual 4K monitors, if that matters. Specifics below: > > Operating System: Fedora Linux 35 > KDE Plasma Version: 5.23.3 > KDE Frameworks Version: 5.89.0 > Qt Version: 5.15.2 > Kernel Version: 5.15.11-200.fc35.x86_64 (64-bit) > Graphics Platform: X11 > Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz > Memory: 31.2 GiB of RAM > Graphics Processor: Mesa Intel® HD Graphics 630 > > I'd be great to have this oddity fixed. Much appreciation for all that you > all do to maintain KDE. Not sure I'd using Linux were it not for KDE. First, a warning born from experience: If you are in a Plasma-Wayland-session, do not switch off your monitor(s) and do not try to suspend/hibernate your PC. And check the energy-settings for these, so that it doesn't happen automatically. Otherwise you may crash your system and perhaps encounter data-loss. See: https://bugs.kde.org/show_bug.cgi?id=438839. Our problem here has nothing to do with your hardware, the kernel etc. It's been introduced with Plasma-5.19 and still exists in later versions. If you have a tcl/tk program on autostart, remove it from there. And if you have one running, shut it down before you log off etc. It may an other program(-class) in you case, you'll have to find out. But I'm pretty sure that if you manually shut down *all* programs you can see in the taskbar before trying to log out etc., it will always succeed. However, this is impractical for normal use. Alternatively, you could go back to long-term-version 5.18.x. Don't know whether that is still being maintained. HTH.
(In reply to imaginator from comment #46) > ....But I'm pretty sure > that if you manually shut down *all* programs you can see in the taskbar > before trying to log out etc., it will always succeed. However, this is > impractical for normal use. > HTH. Just fyi - shutting down all programs before attempting the logout does not work for me. In my case once I'm done configuring my system after the new install, I only rarely need to do a logout/re-login; so I'll just live with it. I did inspect the system log for the time span where I invoked the logout; but I can't claim to be able to make enough sense of it to truly confirm it is this particular bug I have been experiencing. I do see quite a bit of warnings and errors; most seem 'normal' to me. However there are three lines that show: Dec 28 17:59:25 jeffFedora kscreen_backend_launcher[1535]: The X11 connection broke (error 1). Did the X11 server die? Dec 28 17:59:25 jeffFedora kdesud[50170]: kf.su.kdesud: Fatal IO error, exiting... Dec 28 17:59:25 jeffFedora systemd[1168]: dbus-:1.2-org.kde.KScreen@0.service: Main process exited, code=exited, status=1/FAILURE (If it matters, due to a few Wayland issues I just now always login to X11; but, again I experience this issue independent of Wayland or X).
(In reply to Jeffrey Rocchio from comment #47) > (In reply to imaginator from comment #46) > > > ....But I'm pretty sure > > that if you manually shut down *all* programs you can see in the taskbar > > before trying to log out etc., it will always succeed. However, this is > > impractical for normal use. > > HTH. > Just fyi - shutting down all programs before attempting the logout does not > work for me. Too bad - makes it even harder for you. ;) But this may offer a little relief: can you still log into a virtual terminal via Ctrl + Alt + F2 when you encounter the problem? If you can, entering ps -e | grep plas should output something like this: 32002 ? 00:00:00 startplasma-x11 32136 ? 00:00:12 plasmashell You could then kill the Plasma-session by kill [process-number for startplasma-x11] This would spare you a full reboot and should bring you back to the login-screen. > > In my case once I'm done configuring my system after the new install, I only > rarely need to do a logout/re-login; so I'll just live with it. I did > inspect the system log for the time span where I invoked the logout; but I > can't claim to be able to make enough sense of it to truly confirm it is > this particular bug I have been experiencing. I do see quite a bit of > warnings and errors; most seem 'normal' to me. However there are three lines > that show: > > Dec 28 17:59:25 jeffFedora kscreen_backend_launcher[1535]: The X11 > connection broke (error 1). Did the X11 server die? > Dec 28 17:59:25 jeffFedora kdesud[50170]: kf.su.kdesud: Fatal IO error, > exiting... > Dec 28 17:59:25 jeffFedora systemd[1168]: > dbus-:1.2-org.kde.KScreen@0.service: Main process exited, code=exited, > status=1/FAILURE I've had the problem a few times lately (when I forgot to close that particular program mentioned earlier) but cannot find any of those lines in my system-log. It's a system-V-system, though. > > (If it matters, due to a few Wayland issues I just now always login to X11; > but, again I experience this issue independent of Wayland or X). This seems to be independent of X or Wayland. And as I see it, it's pretty clear when and where the problem was introduced (see comment #40).
Some new insights on this one, perhaps for future generations of Plasma developers: The hangs on my system(s) are absolutely reproduceable and occur - when "Ding" (tcl/tk; process "wish") is running - only when logging out, not when restarting - only when the window containing "Ding" (tcl/tk) is minimized or not minimized but not on the current (virtual) desktop - and - as said before - only in Plasma >= 5.19. FWIW, here are excerpts from the process tree: Plasma-5.20.5 ************* [...] ├─org_kde_powerde───4*[{org_kde_powerde}] ├─plasmashell─┬─ksysguardd │ ├─wish───{wish} │ └─42*[{plasmashell}] ├─polkit-kde-auth───4*[{polkit-kde-auth}] [...] Plasma-5.18.8 ************* init─┬─DiscoverNotifie───3*[{DiscoverNotifie}] ├─5*[agetty] [...] ├─upowerd───2*[{upowerd}] ├─wish───{wish} ├─xembedsniproxy───2*[{xembedsniproxy}] └─xfconfd───2*[{xfconfd}]
New install of Fedora 35 KDE pin. Fully updated as of 5/6/22 I don't know what happened but I could not log out. Found someone advised install GDM, enable it, reboot, login, then switch back to SDDM. It fixed my issue. Logout no longer froze. Tried multiple times I then immediately tried to choose a different Application Style (specifically Fusion, though I don't know if this is relevant). I changed my setting, applied. For fun I tried to log out, and immediately I was frozen again. Rebooted, switched back to GDM, reboot, switch back to SDDM, and I was able to logout without problems again. Confirmed this 3x after changing application style. Hope this helps in the efforts, or if someone can confirm what I am seeing. Results my vary, I'm sure.
(In reply to crjackson from comment #50) > > Rebooted, switched back to GDM, reboot, switch back to SDDM, and I was able > to logout without problems again. Confirmed this 3x after changing > application style. > > Hope this helps in the efforts, or if someone can confirm what I am seeing. > Results my vary, I'm sure. This is very interesting. It implies a configuration problem. I'll run some tests and see if I can find out which files are being modified.
v5.25.4, Fedora 36. SDDM will always crash and hang the system if logging out from a Wayland-session. Logging out to GDM works fine.
Switching to GDM and back to SDDM helps, thanks to the comments (with plasma-5.25.5). Logout with GDM works fine too.
Same on Fedora 36 KDE Spin with Zawertun corp enabled for the newest KDE. The workaround is to restart the sddm.service: > sudo systemctl restart sddm.service See https://ask.fedoraproject.org/t/user-logout-freezes-system-fedora-36-kde-spin/24580
This has been fixed in SDDM itself; see https://github.com/sddm/sddm/issues/1476. Just need to wait for a new version of it to eventually get released.
(In reply to Nate Graham from comment #55) > This has been fixed in SDDM itself; see > https://github.com/sddm/sddm/issues/1476. > > Just need to wait for a new version of it to eventually get released. Well, that won't solve my problem with "Ding", already described in detail. That Plasma since 5.19 is not capable any more of orderly terminating the session when this harmless little program is loaded, is just hard to believe. A glitch like that would have been embarrassing even for Windows 3.1. And that was released thirty years ago.
Just saw that this bug has been marked "Resolved". As this is certainly not the case, it should be reopened - if you are serious about fixing bugs in Plasma. In the meantime I will just continue to try hard to think of closing "Ding" before rebooting etc. This is funny!
Your issue with "Ding" is something else. Basically the problem here is that a stuck process can delay logout for 120 seconds by default with systemd. That time is configurable by the user and the distro though. So there are two ways that this kind of problem can be fixed: 1. The targeted solution: fix the app in question so it doesn't hang on quit. That's what happened with SDDM, which is what the bug report was originally about. Drawback: potentially need to fix many things. It's a gave of whack-a-mole. 2. The nuclear solution: at the user or distro level, set the timeout to something short like 5 seconds. Drawback: still delays logout by some amount of time, even if it's not as long. Not really a true solution to the problem. Neither can be done by KDE. The first option needs to be changed by individual apps, and the second option needs to be changed by distros or users. Both can also be done, but neither can be done by KDE. Hopefully that clarifies things a bit.
(In reply to Nate Graham from comment #58) > Your issue with "Ding" is something else. > > Basically the problem here is that a stuck process can delay logout for 120 > seconds by default with systemd. That time is configurable by the user and > the distro though. > > So there are two ways that this kind of problem can be fixed: > 1. The targeted solution: fix the app in question so it doesn't hang on > quit. That's what happened with SDDM, which is what the bug report was > originally about. Drawback: potentially need to fix many things. It's a gave > of whack-a-mole. > 2. The nuclear solution: at the user or distro level, set the timeout to > something short like 5 seconds. Drawback: still delays logout by some amount > of time, even if it's not as long. Not really a true solution to the problem. > > Neither can be done by KDE. The first option needs to be changed by > individual apps, and the second option needs to be changed by distros or > users. Both can also be done, but neither can be done by KDE. > > Hopefully that clarifies things a bit. Thanks for your reply. I'm afraid that systemd and timeouts have nothing to do with the problem since the system is "System V". The trouble began with Plasma-5.19. Any version before that (incl. Plasma-4) had no problem with terminating Ding. Nor does xfce (same PC). So, while I cannot rule out a bug in Ding somewhere, it seems more likely that changes in Plasma-5.19 are the root cause here, not the app itself or the init procedure. "Ding" is just a shell skript plus tcl/Tk frontend. It never causes any other problem and can always be terminated manually. Why Plasma should no longer be able to do that, eludes me. Moreover, if an app blocks Plasma's logout procedure, Plasma should be able to detect that and air a warning instead of hanging beyond resuscitation. What makes matters worse is that there seems to be no way of binding a Ding-closing script to Plasma's session-terminating procedure. So it's either "Don't forget to close Ding!!!" or "Dammit! Not again!". Both options seem somewhat anachronistic in 2022.
As a workaround, I might suggest you create a script that kills "Ding" and put it in $HOME/.config/plasma-workspace/shutdown directory. See https://docs.kde.org/trunk5/en/plasma-workspace/kcontrol/autostart/index.html.
(In reply to popov895 from comment #60) > As a workaround, I might suggest you create a script that kills "Ding" and > put it in $HOME/.config/plasma-workspace/shutdown directory. > > See > https://docs.kde.org/trunk5/en/plasma-workspace/kcontrol/autostart/index. > html. Thanks for your suggestion. But I've tried that already: #! /bin/bash if [[ $(pgrep wish) ]]; then pkill wish fi As Ding uses Tk, the process is "wish". The script as such works: when it is executed in a Plasma session, Ding is terminated as expected. But when I log out via Plasma's logout menu, Plasma hangs as it always does when Ding is running. And only killing "startplasma-x11" in a VT brings me back to the dm's login-screen.
If you're not using Systemd, then your problem has completely different root causes and potential resolutions compared the bug described here, and should be discussed elsewhere. It's also probably not a KDE bug, as both SysVinit and Systemd are are far below any KDE code. > Both options seem somewhat anachronistic in 2022. Indeed, which is why one of the reasons SystemD was invented was to fix this problem. :) It allows deterministic ordering of startup and shutdown process and fine-grained control over how long a stuck process can halt shutdown. The distro just has to set that up properly. So this is a solved problem in 2022 if you're using modern software that's configured well. I would recommend that you discuss the "Ding" problem with your distro.
(In reply to Nate Graham from comment #62) > If you're not using Systemd, then your problem has completely different root > causes and potential resolutions compared the bug described here, and should > be discussed elsewhere. It's also probably not a KDE bug, as both SysVinit > and Systemd are are far below any KDE code. > > > Both options seem somewhat anachronistic in 2022. > Indeed, which is why one of the reasons SystemD was invented was to fix this > problem. :) It allows deterministic ordering of startup and shutdown process > and fine-grained control over how long a stuck process can halt shutdown. > The distro just has to set that up properly. One reason why I finally said "Good riddance!" to systemd was that enervating "A stop job is running...". At one point I was sufficiently fed up with that. I switched to System V and never looked back. > > So this is a solved problem in 2022 if you're using modern software that's > configured well. This seems to imply that one now has to choose between Plasma + "modern" systemd (suggesting that "modern == good") or having to accept certain problems. This is new to me, since AFAIK, KDE once pledged that Plasma would continue to work with System V. If this is not the case anymore, KDE should state it clearly, so that people know and can adapt their choices accordingly. > > I would recommend that you discuss the "Ding" problem with your distro. "Inside-out" thinking instead of "outside-in" may ease problems in the short run but in the long run is a proven recipe for disaster.
Plasma isn't involved at all with how Ding interacts with either SysVinit or Systemd. We don't have the power to fix your problem in KDE--or the original one discussed here, for that matter, which is why it's marked as an upstream problem, and had to be fixed upstream.
> Moreover, if an app blocks Plasma's logout procedure, Plasma should be able to detect that and air a > warning instead of hanging beyond resuscitation. That's reasonable, but it needs its own bug report to track it so it doesn't get lost here. Can you file one? Thanks!
(In reply to Nate Graham from comment #64) > Plasma isn't involved at all with how Ding interacts with either SysVinit or > Systemd. We don't have the power to fix your problem in KDE--or the original > one discussed here, for that matter, which is why it's marked as an upstream > problem, and had to be fixed upstream. What you seem to ignore is that for many, many years Plasma worked well with "Ding". Problems surfaced only relatively recently with a certain version.
Again, Plasma isn't involved with how your init system terminates processes at logout. So any Plasma upgrade that seemed to have introduced the problem is coincidental, and the problem actually came from a change to the app, the init system, your distro's configuration of the init system, or a local change you made that happened to happen at around the same time as the Plasma upgrade. I can't put it any more clearly than that.
Just played around with the Ding on openSUSE Tumbleweed + systemd and found that this problem is present here as well. And, Nate, I'm afraid this is a Plasma issue, since I solved it by switching "Settings" > "Display and Monitor" > "Compositor" > "Keep Window Thumbnails" option to "Always". imaginator@mailbox.org, can you try this for yourself? In any case, it's better to file a new bug report for this.
You might have noticed the warning message that appears when you turn that setting on that specifically warns about problems related to communicating status to the window manager. :) So I'm not surprised that turning it on causes problems. When you turn it on, only you can make the determination that the bugs it introduces are worth it to you.
Nate, you misunderstood. The default value for that option is "Only for Shown Windows", which is where this problem with the Ding occurs. If I change this option to "Always", then the problem disappears (in my case). Judging by the text in the warning message, the Plasma somehow suspends the work of the minimized windows, and perhaps that is what is causing this behavior of this Ding.
(In reply to popov895 from comment #68) > Just played around with the Ding on openSUSE Tumbleweed + systemd and found > that this problem is present here as well. And, Nate, I'm afraid this is a > Plasma issue, since I solved it by switching "Settings" > "Display and > Monitor" > "Compositor" > "Keep Window Thumbnails" option to "Always". > imaginator@mailbox.org, can you try this for yourself? > > In any case, it's better to file a new bug report for this. Spot on! Yes, setting "Keep Window Thumbnails" option to "Always" solves it. Logged out twice without problems after that. Great you figured this out! I now remember that I had this setting for a long time because it made the background-colors of the icons in the taskbar more to my liking (lighter). But IIRC this was no longer necessary when a new Plasma version came out and so I set that option back to "Never" - after all, you get a warning when setting it to "Always". So it may indeed be that the switch to "Never" coincided with that certain Plasma version with which the problem seemingly began. Nate, would you consider this a Plasma bug? If so, I'd write a bug report in the coming days.
That's weird. It does sound like a Plasma bug, yeah. Well, a KWin bug. A new bug report for it would be appreciated.
(In reply to Nate Graham from comment #72) > That's weird. It does sound like a Plasma bug, yeah. Well, a KWin bug. A new > bug report for it would be appreciated. Alright, filed a report: https://bugs.kde.org/show_bug.cgi?id=459643.
Thank you!