If network connection is lost while a SMB share is mounted with CIFS, or the SMB share becomes unavailable on the network for other reasons, the panel and other desktop functionality hangs for several minutes. During this time, attempting to open the menu opens only a blank, semi-transparent pane, which sticks in the 'open' position. Clicking other panel object or tray items - such as the 'network manager' icon, yields no response. Dolphin becomes unresponsive. In short, all desktop environment graphical elements are rendered almost entirely dysfunctional. Konsole does still work to a point, however attempting to enter or list the SMB directory hangs the session. In that case, another terminal session (tab or window) needs to be opened to resume using Konsole. After several minutes of this hang, normal service appears to be resumed. STEPS TO REPRODUCE 1. Mount an SMB share with CIFS. 2. Disconnect from the network. 3. Attempt to open the main menu on the panel. OBSERVED RESULT: As summarised above. EXPECTED RESULT: Desktop functionality remains unaffected by network loss and associated loss to access to the source of the CIFS mounted SMB share. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.12.6 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5
Can you verify [1] fixes this? I think this should be backported to 5.12 (sans the notification) since the setup you describe is most likely in a corporate environment where Plasma LTS runs instead of latest and greatest. [1] https://cgit.kde.org/plasma-workspace.git/commit/dataengines/soliddevice?id=e1c19ce4daf92a14dee44b44d199672034a346c0
That's a good idea, Kai. Make it so! ;)
(In reply to Kai Uwe Broulik from comment #1) > Can you verify [1] fixes this? I haven't had the time to build from source to apply the patch as yet (which I assume is the only way to test this?). However, from the description of the issue the patch fixes, it'd appear to be what I'm experiencing, so I'm hopeful it would. > I think this should be backported to 5.12 (sans the notification) since the > setup you describe is most likely in a corporate environment where Plasma > LTS runs instead of latest and greatest. Yes, a backport would be very helpful. I'm not on a corporate network, but am running Kubuntu 18.04 with SMB served from FreeNAS in a SOHO environment - so yes, it'd be Plasma LTS. FYI, I did upgrade to Kubuntu 18.10, which is on Plasma 5.13.5, and the issue is also evident there. A work around, which will suffice until a backport, seems to be to avoid having the SMB shares mounted in the home directory, or linked therefrom. That prevents the panel, Dolphin and other Desktop functionality from locking up and hanging. Thanks for the info, looking forward to the backport.
Git commit be3b80e78017cc6668f9227529ad429150c27faa by Kai Uwe Broulik, on behalf of Oleg Solovyov. Committed on 19/10/2018 at 13:29. Pushed by broulik into branch 'Plasma/5.12'. Plasmashell freezes when trying to get free space info from mounted remote filesystem after losing connection to it Summary: Related: bug 397537 Earlier plasmashell assumed that you'll get free space info immediately (which is not true in case of losing connection to server containing a mounted filesystem - statfs will wait for response forever and freeze everything since it's happening in main thread) I moved obtaining that info into different thread so that case won't freeze anything anymore. It creates exactly one thread per one path. If a path is already being processed, new thread won't be created. Also I implemented a timer used to notify about broken connection after 15 seconds. Reviewers: broulik, ngraham, davidedmundson Reviewed By: broulik Subscribers: ngraham, anthonyfieroni, davidedmundson, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D14895 Backported to 5.12 LTS (sans notification due to new strings) for impact to corporate setups (cherry picked from commit e1c19ce4daf92a14dee44b44d199672034a346c0) M +22 -7 dataengines/soliddevice/soliddeviceengine.cpp M +2 -0 dataengines/soliddevice/soliddeviceengine.h https://commits.kde.org/plasma-workspace/be3b80e78017cc6668f9227529ad429150c27faa
I backported the fix to Plasma 5.12 LTS. Unfortunately 5.13 isn't actively maintained anymore so you would have to ask your distribution to backport this fix or upgrade to Plasma 5.14, if possible. Marking this bug as duplicate of the actual bug now, thanks for your feedback! *** This bug has been marked as a duplicate of bug 397537 ***
(In reply to Kai Uwe Broulik from comment #5) > I backported the fix to Plasma 5.12 LTS. Unfortunately 5.13 isn't actively > maintained anymore so you would have to ask your distribution to backport > this fix or upgrade to Plasma 5.14, if possible. > > Marking this bug as duplicate of the actual bug now, thanks for your > feedback! Superb, thanks very much for your exceptionally quick resolution of this issue! Much appreciated!
(In reply to Kai Uwe Broulik from comment #5) > I backported the fix to Plasma 5.12 LTS. Unfortunately 5.13 isn't actively > maintained anymore so you would have to ask your distribution to backport > this fix or upgrade to Plasma 5.14, if possible. Okay, I've now tested this after adding the Kubuntu backports PPA to the 18.10 system and upgrading to Plasma 5.14.1 (KDE Frameworks 5.51.0). The issue with the panel is indeed fixed. However, issues to still persist, in terms of access to the paths where the SMB (CIFS) share is mounted. When network is down (or the share becomes unavailable over the network, for whatever reason), not only does the mounted directory become unresponsive, but so does the entire directory path. For example, if the share is mounted at /home/dan/remote_data, then loss of network renders /home and all its subdirectories unresponsive. This applies both to attempts to open directories with Dolphin, and also access those directories with the CLI. Being that this is a slightly different (although related issue), should I open a new bug report? And if so, what would be the most appropriate Product/Component category, since this involves Plasma GUI applications (i.e. Dolphin), network stack, CIFS ... Thanks.
> Being that this is a slightly different (although related issue), should I open a new bug report? Yes please. Report it against whichever process is frozen and include a gdb stacktrace of the frozen state. It can always be moved