SUMMARY When time-consuming commands are triggered (e.g. connecting to a slow-to-connect wireless/wired network, connecting to a wireless/wired network with a very high packet loss or latency) from the NetworkManager widget,the whole plasma desktop is frozen until the command finishes. STEPS TO REPRODUCE 1. Setup a wireless/wired network that takes several seconds to connect to, or to access the internet 2. try to connect to such network using the NetworkManager 3. click on other widgets or application launcher OBSERVED RESULT the widget panel will become stuck all other actions in plasma (like opening other widgets or the application launcher will be triggered once the NetworkManager finishes its action (regardless of failure/success) EXPECTED RESULT NetworkManager widget should stay responsive to user actions and not freeze. All other widgets and the rest of plasma should not be stuck SOFTWARE/OS VERSIONS Linux/KDE Plasma: Operating System: Manjaro Linux KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.3 Kernel Version: 5.1.8-1-MANJARO OS Type: 64-bit Processors: 8 × Intel® Xeon® CPU E3-1505M v6 @ 3.00GHz Memory: 31,3 GiB of RAM ADDITIONAL INFORMATION In normal day-to-day tasks, it can seem just a big laggy. When there are internet issues by ISP, switching from a network to the other causes the Plasma desktop to freeze continuously for 10 seconds or more this issue https://bugs.kde.org/show_bug.cgi?id=299347 might be related
I can confirm this annoying issue, which I have experienced several when I tried to connect to a (by my self) wrongly configured network. SYSTEM Operating System: Manjaro Linux KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0 Kernel Version: 5.1.16-1-MANJARO
*** Bug 410859 has been marked as a duplicate of this bug. ***
Can confirm. Happens daily. SYSTEM Operating System: Manjaro Linux KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.60.0
This issue is really giving me headache. I try to set up a VPN connection and besides OpenConnect forgetting the "saved credentials" all the time, additionally the system freezes for ~10-20 seconds, eg whenever I the connection fails. :-| Is there anything we can do to help you debugging it?
*** Bug 416451 has been marked as a duplicate of this bug. ***
Just happened again, when I had issues with my internet connection due to provider failure. When opening the applet, the whole Plasma Desktop froze for quiet some time (increasing the frustration over the non-working internet even more). However, switching the TTY, killing '/usr/bin/networkmanager' and switching back, made the desktop instantaneously smooth again. Any idea how to debug this for you? This is really annoying. :-(
*** Bug 419443 has been marked as a duplicate of this bug. ***
*** Bug 423879 has been marked as a duplicate of this bug. ***
*** Bug 432947 has been marked as a duplicate of this bug. ***
*** Bug 443689 has been marked as a duplicate of this bug. ***
In version 5.23.3 I observe much better connection to to WiFi and Wireguard: no freezes. Although in this particular scenario there are still significant freezes (every time for 4-8 seconds): 1. Turn ON both WiFi and Wireguard. 2. Turn OFF only WiFi.
To me this still happens in 5.23.3 when there is a bad connectivity, for instance, not long ago I had a bad connection with my provider and there was 50% packet loss, anything I do on network applet, froze plasma for some time.
(In reply to soshial from comment #11) > In version 5.23.3 I observe much better connection to to WiFi and Wireguard: > no freezes. Although in this particular scenario there are still significant > freezes (every time for 4-8 seconds): > > 1. Turn ON both WiFi and Wireguard. > 2. Turn OFF only WiFi. Cannot reproduce on git master. It could be also a bug in older versions of NetworkManager. On my system the version is 1.32.12
> Cannot reproduce on git master. It could be also a bug in older versions of NetworkManager. On my system the version is 1.32.12 Whether the particular bug in networkmanager-* (to me was in the openvpn plugin) gets fixed is irrelevant to this issue. IMHO it only uncovered a sub-optimal design decision in the widget. It all boils down to that plasma-nm blocks until a response from NetworkManager comes which in turn blocks the whole plasma.
Created attachment 144954 [details] status bar freezes after login (notice how the time jumps several hours)
(In reply to Kiril Vladimirov from comment #14) > > Cannot reproduce on git master. It could be also a bug in older versions of NetworkManager. On my system the version is 1.32.12 > > Whether the particular bug in networkmanager-* (to me was in the openvpn > plugin) gets fixed is irrelevant to this issue. IMHO it only uncovered a > sub-optimal design decision in the widget. It all boils down to that > plasma-nm blocks until a response from NetworkManager comes which in turn > blocks the whole plasma. I can reproduce it now. Need a bad WiFi connection.
Can be easily reproduced with a router: remove WAN cable from the router and wait for 5 seconds. KDE Plasma will freeze for 30 seconds.
Plasma 5.24.2 and Fedora 35 - seeing this exact same issue. Easiest way to trigger it, I have found, is start a wireguard connection and then put the computer to sleep. When it wakes, it takes a bit for the wireguard connection to come back online. In the interim, the entire system locks up. Anything that causes a connection to drop, even momentarily, makes Plasma unusable, sometimes until a reboot.
To find all blocking calls one can run: Q_DBUS_BLOCKING_CALL_MAIN_THREAD_WARNING_MS=0 plasmashell --replace |& grep org.freedesktop.NetworkManager Don't paste it here. All are in the property fetching. We can do an obvious speedup by dropping some Gets that are then retrieved by a GetAll anyway for the same object and potentially some caching. Ultimately we need this to be async. All issues are in libnm-qt
The root cause of this on the NetworkManager side seems to be systemd-resolved choking on DNS changes. Once I stop/disable/mask the systemd-resolved service, the freezing stops.
*** Bug 452067 has been marked as a duplicate of this bug. ***
Some of these blocking calls have been reduced. It would be good to know it the issue persists.
The issue does still persist, but the wait time is much shorter than before. I believe the reduced blocking calls are working, but the issue is not all the way gone. Here's my system info: Operating System: EndeavourOS KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.17.4-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2
(In reply to Dashon from comment #23) > The issue does still persist, but the wait time is much shorter than before. > I believe the reduced blocking calls are working, but the issue is not all > the way gone. > Here's my system info: > Operating System: EndeavourOS > KDE Plasma Version: 5.24.4 > KDE Frameworks Version: 5.93.0 > Qt Version: 5.15.3 > Kernel Version: 5.17.4-arch1-1 (64-bit) > Graphics Platform: X11 > Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor > Memory: 31.3 GiB of RAM > Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2 My apologies for getting back to you so late.
My apologies for getting back to you so late.
I no longer have this issue in 5.25.1. Might have been fixed in 5.25.0, but I didn't check then.
Can anyone else who was previously experiencing the issue confirm that?
There were some relevant patches to kde's network manager: commit 6508fa524fa2d3ed058f7945fa9eb61b7647518d Author: David Redondo <kde@david-redondo.de> Date: Thu Mar 10 12:01:28 2022 +0100 that removed some blocking calls. It does not remove all blocking calls only cut it down significantly.
Please reopen if it's an issue affecting users after 5.27