Created attachment 140790 [details] thread apply all bt SUMMARY Plasmashell tends to hang/completely freeze when a mounted network file system temporarily does not respond. Most of the times, the panels will recover after some minutes but sometimes they don't. I've now seen a freeze which didn't recover and I had to SIGKILL plasmashell to restart it, even `--replace` did not work. I'm not sure if a mounted file system was involved this time (see Additional Information below). Take note that the network mounts are completely unrelated, there's nothing on the panel that even loads data from it. In earlier versions this was also caused by plasma widgets loading data from network while the internet connection temporarily stalled. I've since removed all widgets that load data from network (like the weather widget). But I believe this incident may be caused by the disk usage warning plugin of plasma when it tries to access disk usage data from a non-responding mount. Conclusion: Plasma should not block and maybe wrap a timeout handler around queries that may potentially stall due to external reasons. However, this incident may be different. A plasma dev may have better insights. I'll attach a short and full gdb backtrace I was able to fetch from the hanging pid. Possible bug reports covering the mount-related issue but probably not a duplicate of this: #413110, #416972, #272361 STEPS TO REPRODUCE 0. The backtrace may not be about this particular hang: 1. Use network mounts somewhere below your home directory 2. Cut the network connection to stall access to these mounts 3. Observe plasmashell freezing and recovering minutes later OBSERVED RESULT Plasma panels stop responding to clicks and freeze with whatever content they did currently render. EXPECTED RESULT Plasma should detect timeouts and recover in one or another way, as a last resort it could kill itself and restart - which helped in this particular case: I SIGKILLed it and restarted it. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux (available in About System) KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This particular freeze may be related to this dmesg entry: [686470.331086] BUG: unable to handle page fault for address: 000000020ee80000 [686470.331091] #PF: supervisor write access in kernel mode [686470.331092] #PF: error_code(0x0002) - not-present page [686470.331093] PGD 0 P4D 0 [686470.331096] Oops: 0002 [#1] PREEMPT SMP [686470.331098] CPU: 1 PID: 1919 Comm: QSGRenderThread Not tainted 5.10.57-gentoo #1
Created attachment 140791 [details] thread apply all bt full
In general, this is why KIO exists: to provide asynchronous, non-blocking access to flaky network resources. When you bypass KIO and mount them directly, you're undoing that protection. What kinds of things have you manually mounted and why?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/603
(In reply to Nate Graham from comment #2) > In general, this is why KIO exists: to provide asynchronous, non-blocking > access to flaky network resources. When you bypass KIO and mount them > directly, you're undoing that protection. > > What kinds of things have you manually mounted and why? The mount in question is a samba share mounted over VPN when I work remotely at home. The problem with KIO is that it is not transparently available to all software, i.e. when opening a document with LibreOffice, it will be copied to a temporary directory, then copied back on save/quit. This removes the ability of LibreOffice to lock the file and detect concurrent changes of the source file. And it also breaks relation between the original file path and the path opened in the application: This is not what I expect to be transparency. Also, non-KDE programs cannot even parse the paths: Sometimes, KIO paths become directly passed to the program instead of copying the file to a local path first. CLI utilities cannot even be used to navigate KIO mounts. KIO should probably become a fuse module - which would then probably just introduce this exact reported behavior which KIO tries to avoid. KIO is nice if you exclusively only use KDE software - but that's quite unrealistic in practice. Also, it falls apart once you drop to the CLI level, which is what a lot of my workflow consists of. I'm actually using KIO for things like managing files over sftp remotely via Dolphin - and it works great then. But its field of use is very limited to me. Maybe comment #3 solves it for me.
That's what kio-fuse was meant to solve. Do you have it installed?
Git commit a4c711a411f47e11c5327efa0dd40c12b26875e5 by Méven Car, on behalf of Fushan Wen. Committed on 18/10/2021 at 16:34. Pushed by meven into branch 'master'. taskmanager: Use SkipMimeTypeFromContent flag when creating KFileItem This prevents plasmashell from freezing at opening the context menu when there is no network and there are files on a network mount in "Recent Files" section. Related: bug 443465, bug 406110 M +2 -6 applets/taskmanager/plugin/backend.cpp https://invent.kde.org/plasma/plasma-desktop/commit/a4c711a411f47e11c5327efa0dd40c12b26875e5
(In reply to Nate Graham from comment #5) > That's what kio-fuse was meant to solve. Do you have it installed? Ah ok, didn't know how it worked - and it was eventually kicked from the system previously by some conflict. I now reinstalled it and reloaded my systemd daemon. Observation: Opening files for non-KIO aware programs spawns a fuse mount. Looks like it doesn't do that for KIO-aware programs (at least I see no additional folders created in the mount directory). Let's see how I can use that for me. But I will still depend on NFS mounts from the local network, e.g. by backup repository will be mounted via an automounter (daily full system backup with borg). Usually, the NAS is available 24x7 but sometimes it will restart for updates - and that's when the plasmashell rarely but eventually blocks. Why does it look for network mounts that actually have no business with my user account, or does it? Any way to debug this when it happens?
I don't know, sorry. If you configure Borg with a nfs:// URL, hopefully kio-fuse will notice and automatically mount a fuse mount underneath it and everything will be nice and transparent. That should work. If it doesn't please file a bug report to kio-fuse. :)
I'm not sure how that could even work. (a) it runs from a different session context, it's running from systemd system service while kio-fuse is a user session dbus service (b) this would imply that I could use `ls nfs://serverip/` which I obviously cannot (I tried, spoiler: doesn't work) Maybe that could be solved if I knew how KDE/KIO decides whether to use KIO and when to fall back to KIO fuse. How does this heuristic work?
OTOH, I could try migrating to a borg client/server model instead of opening the repository via filesystem directly. This also decouples some security concerns as the borg service limits access patterns to those needed for repository access.
I can confirm this bug, even though in my case Plasmashell hangs and never recovers. Even restarting it has no effect other than making Plasma freeze as soon as it starts loading, leaving me with a non-functional desktop. I can reproduce it if a mounted NFS share becomes not available.
I partially found automounts triggering the problem. With automounts enabled, right clicking on dolphin window icons or starting konsole (probably every app that is somehow involved in checking mount point stats) can stall either plasma (when a context menu is displayed) or stall konsole startup for multiple seconds up to a minute. Interestingly, just using "cd" to switch to a directory with automount point and running "ls" almost instantly returns and shows the directory. This affects both NFS and local automounts for me but also remote filesystems mounted via kio (and the latter seem to contribute a lot more to the stalls). Once NFS automounts are mounted, the system does no longer stall konsole, kio is eventually cached by then but the dolphin window icon context menu is still affected and blocks plasma while stalled. On a second system which is configured almost identically, the same behavior cannot be observed or it is much less pronounced.
#
Can easily confirm with ``` sshfs user@host:/ mymount ``` where host is a remote, which does not respond or even not exist. Execute the command a few times until it actually takes a while before it times out to make it easier to reproduce: In the meantime Plasma's panel on 6.3.5 are frozen. I've had this a few times now in a real world scenario.
Maybe there's a similar issue in dolphin: If there are many network shares (automounted or kio), dolphin takes a few seconds before opening its window on first start. Successive starts are much faster, until I wait long enough for the shares to disconnect on idle. If one of the network shares is not reachable, dolphin will take very long to start. I think it is probing the free space on each share. Plasma probably triggers a similar behavior through a common component used by both programs? If a share/mount is not mounted yet (kio, automount), those should probably be left alone and be shown as disconnected until the user clicks on them. And plasmashell should do the same: not touch mounts that are disconnected and would be automounted.
Thanks to everyone who put in the energy for this ticket. This has been a daily annoyance for me for my entire time using KDE Plasma and it's good to see this ticket exists. I can confirm previous comment #15 from Kai Krakow, because I also have mounted NFS (earlier SMB) shares automounted in my system so I can interact with the files via shell. The disks are spinning up every time I open up dolphin, sometimes also when opening an app like Gwenview. I wish it wouldn't do this. There are no (at least visible) recent files accessed on that drives and I don't want to know the disk free on these drives unless I ask it to. When the server is down I also experienced lockups in Dolphin but I haven't had the "opportunity" to experience this in a while thankfully ;) Maybe something can be done about Dolphin's need to probe the mounts when it's not being asked to by the user? I dislike saying this but in this regard the user experience in Gnome is superior because you can start and use Nautilus and other Gnome apps without it trying to access these drives needlessly. Maybe someone can at least identify what exactly is being requested that is spinning up the drives (and locking) Dolphin during start.
I should have read more of the thread before posting. I'll try and see if kio-fuse solves my issues.
*** Bug 492815 has been marked as a duplicate of this bug. ***
For me, if I have network mounts but the system starts without internet, plasmashell simply does not fully load for a long time. It seems that `KMountPoint::possibleMountPoints` can block when there are some unresponsive network mounts. Not sure whether the fix should be in kio or plasma-workspace/applets/kicker/computermodel.cpp though. The backtrace I get looks like #0 0x00007f14803184ee in fstatat64 () at /usr/lib64/libc.so.6 #1 0x00007f1483e24489 in KMountPoint::possibleMountPoints (infoNeeded=infoNeeded@entry=...) at /home/yifan/kde/src/kio/src/core/kmountpoint.cpp:194 #2 0x00007f1483e31194 in KCoreDirListerCache::forgetDirs (this=0x5587301574f0, lister=0x5587301441d0) at /home/yifan/kde/src/kio/src/core/kcoredirlister.cpp:466 #3 0x00007f1483e3bdf7 in KCoreDirListerCache::listDir (this=0x5587301574f0, lister=lister@entry=0x5587301441d0, dirUrl=..., _keep=false, _reload=true) at /home/yifan/kde/src/kio/src/core/kcoredirlister.cpp:118 #4 0x00007f1483e3d20f in KCoreDirLister::openUrl (this=this@entry=0x5587301441d0, _url=..., _flags=..., _flags@entry=...) at /home/yifan/kde/src/kio/src/core/kcoredirlister.cpp:2132 #5 0x00007f1479f6ab75 in KFilePlacesModelPrivate::KFilePlacesModelPrivate (this=0x5587301427b0, qq=<optimized out>) at /home/yifan/kde/src/kio/src/filewidgets/kfileplacesmodel.cpp:181 #6 0x00007f1479f6aced in KFilePlacesModel::KFilePlacesModel (this=this@entry=0x558730143ce0, parent=parent@entry=0x558730144570) at /home/yifan/kde/src/kio/src/filewidgets/kfileplacesmodel.cpp:215 #7 0x00007f13b0ad4eb4 in FilteredPlacesModel::FilteredPlacesModel (this=0x558730144570, parent=<optimized out>) at /home/yifan/kde/src/plasma-workspace/applets/kicker/computermodel.cpp:24 #8 0x00007f13b0ad59e9 in ComputerModel::ComputerModel (this=0x5587301452c0, parent=<optimized out>) at /home/yifan/kde/src/plasma-workspace/applets/kicker/computermodel.cpp:128 #9 0x00007f13b0ab9cbb in QQmlPrivate::QQmlElement<ComputerModel>::QQmlElement (this=0x5587301452c0) at /usr/include/qt6/QtQml/qqmlprivate.h:99 #10 QQmlPrivate::createInto<ComputerModel> (memory=0x5587301452c0) at /usr/include/qt6/QtQml/qqmlprivate.h:174 #11 0x00007f1482147384 in QQmlType::create(void**, unsigned long) const () at /usr/lib64/libQt6Qml.so.6 #12 0x00007f1482147434 in QQmlType::createWithQQmlData() const () at /usr/lib64/libQt6Qml.so.6 #13 0x00007f1482112faa in QQmlObjectCreator::createInstance(int, QObject*, bool) () at /usr/lib64/libQt6Qml.so.6 #14 0x00007f14821064fa in QQmlObjectCreator::setPropertyBinding(QQmlPropertyData const*, QV4::CompiledData::Binding const*) () at /usr/lib64/libQt6Qml.so.6 #15 0x00007f1482109b8e in QQmlObjectCreator::setupBindings(QFlags<QQmlObjectCreator::BindingMode>) () at /usr/lib64/libQt6Qml.so.6 #16 0x00007f148210f8db in QQmlObjectCreator::populateInstance(int, QObject*, QObject*, QQmlPropertyData const*, QV4::CompiledData::Binding const*) () at /usr/lib64/libQt6Qml.so.6 #17 0x00007f14821129af in QQmlObjectCreator::createInstance(int, QObject*, bool) () at /usr/lib64/libQt6Qml.so.6 #18 0x00007f148211abf7 in ??? () at /usr/lib64/libQt6Qml.so.6 #19 0x00007f14820923d6 in QQmlComponentPrivate::beginCreate(QQmlRefPointer<QQmlContextData>) () at /usr/lib64/libQt6Qml.so.6 #20 0x00007f1482092bae in QQmlComponent::beginCreate(QQmlContext*) () at /usr/lib64/libQt6Qml.so.6 #21 0x00007f148414c0d6 in PlasmaQuick::SharedQmlEnginePrivate::endExecute (this=0x558730117ae0) at /home/yifan/kde/src/libplasma/src/plasmaquick/sharedqmlengine.cpp:133 #22 0x00007f1484125234 in PlasmaQuick::AppletQuickItem::itemForApplet (applet=<optimized out>) at /home/yifan/kde/src/libplasma/src/plasmaquick/appletquickitem.cpp:546 #23 0x00007f1484164d49 in ContainmentItem::init (this=0x558730299830) at /home/yifan/kde/src/libplasma/src/plasmaquick/plasmoid/containmentitem.cpp:80 #24 0x00007f148210e004 in QQmlObjectCreator::finalize(QQmlInstantiationInterrupt&) () at /usr/lib64/libQt6Qml.so.6 #25 0x00007f1482095c29 in QQmlComponentPrivate::complete(QQmlEnginePrivate*, QQmlComponentPrivate::ConstructionState*) () at /usr/lib64/libQt6Qml.so.6 #26 0x00007f148209913b in QQmlComponentPrivate::completeCreate() () at /usr/lib64/libQt6Qml.so.6 #27 0x00007f148414bdfb in PlasmaQuick::SharedQmlEngine::completeInitialization (this=0x55873039e160, initialProperties=<optimized out>) at /home/yifan/kde/src/libplasma/src/plasmaquick/sharedqmlengine.cpp:270 #28 0x00007f1484125d2a in PlasmaQuick::AppletQuickItem::itemForApplet (applet=<optimized out>) at /home/yifan/kde/src/libplasma/src/plasmaquick/appletquickitem.cpp:654 #29 0x00007f148413e4fd in PlasmaQuick::ContainmentViewPrivate::setContainment (this=0x558730269e90, cont=0x55872dc8c680) at /home/yifan/kde/src/libplasma/src/plasmaquick/containmentview.cpp:115 #30 0x00007f148413ecc9 in PlasmaQuick::ContainmentView::setContainment (this=<optimized out>, cont=<optimized out>) at /home/yifan/kde/src/libplasma/src/plasmaquick/containmentview.cpp:262 #31 0x0000558725a47258 in ShellCorona::createWaitingPanels (this=0x7ffc3c42aec0) at /home/yifan/kde/src/plasma-workspace/shell/shellcorona.cpp:1624 #32 0x00007f14809b6cc9 in ??? () at /usr/lib64/libQt6Core.so.6 #33 0x00007f14809bd8a5 in QTimer::timerEvent(QTimerEvent*) () at /usr/lib64/libQt6Core.so.6 #34 0x00007f14809a5459 in QObject::event(QEvent*) () at /usr/lib64/libQt6Core.so.6 #35 0x00007f14830fed9e in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt6Widgets.so.6 #36 0x00007f148095a018 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib64/libQt6Core.so.6 #37 0x00007f1480ade200 in QTimerInfoList::activateTimers() () at /usr/lib64/libQt6Core.so.6 #38 0x00007f1480bcfe29 in ??? () at /usr/lib64/libQt6Core.so.6 #39 0x00007f147fc4987d in ??? () at /usr/lib64/libglib-2.0.so.0 #40 0x00007f147fc4acd7 in ??? () at /usr/lib64/libglib-2.0.so.0 #41 0x00007f147fc4aee5 in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #42 0x00007f1480bcd59d in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt6Core.so.6 #43 0x00007f1480965376 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt6Core.so.6 #44 0x00007f148095d159 in QCoreApplication::exec() () at /usr/lib64/libQt6Core.so.6 #45 0x0000558725a0f224 in main (argc=<optimized out>, argv=<optimized out>) at /home/yifan/kde/src/plasma-workspace/shell/main.cpp:188
*** Bug 509402 has been marked as a duplicate of this bug. ***