strace dolphin shows dolphin waiting forever on lstat("/nfsmounteddirectory"). Just because one such directory is not available is no reason for it not even displaying a home dir for example. Reproducible: Always Steps to Reproduce: 1. create an NFS which is unavailable on which lstat can be called 2. observe lstat takes forever 3. run dolphin with probably a place like that configured or any way in which lstat is called by dolphin.
Would it be possible to access the remote server via KIO? The KIO technology has been designed to be out-of-process, to prevent such POSIX deficiencies.
It is an NFS server, so if KIO supports nfs in some way, then yes. I also have ssh access, but this doesn't create the same experience in Dolphin. Clicking on a file downloads the whole file, instead of just exporting a file system abstraction like nfs does.
We are experiencing the same problem. We work in a networked environment with dozens of terabytes of data accessible via NFS on different servers. Whenever NFS is unavailable (server not responding, switch down, etc.) we can no longer browse even our local files in Dolphin. Unfortunately, we cannot use KIO slaves: we also need to access the data using bash scripts and pure C/C++, non-KDE, programs. Is it possible to make Dolphin ignore stalled NFS mounts?
Resetting assignee to default as per bug #305719
*** Bug 305692 has been marked as a duplicate of this bug. ***
Could you try if removing the Places Panel "fixes" the problem? (In reply to comment #3) > Is it possible to make Dolphin ignore stalled NFS mounts? I'm afraid that this is not possible inside Dolphin. We use Solid for getting info about mounted devices. Solid tries to get info about devices synchronously, which means that the entire application will be blocked until this process is finished. AFAIK, it is planned to make Solid asynchronous in KDE 5. In theory, one could put our calls to Solid's functions into a separate thread to prevent the blocking. But I don't really like this solution because every single application using Solid would have to do the same thing. I think it would be far better to resolve the issue inside Solid.
Just to make clear if Solid is really responsible or if there is something that we could do in Dolphin: could you run Dolphin inside gdb and get a backtrace when it blocks?
Waiting for feedback (see comment 7).
may be relevant, similar circumstance in kickoff, bug #184062
I confirm this bug. How to "run Dolphin inside gdb and get a backtrace when it blocks"?
(In reply to comment #10) > I confirm this bug. How to "run Dolphin inside gdb and get a backtrace when > it blocks"? 1. In a terminal, enter "gdb dolphin". 2. At the gdb prompt, enter "r". 3. Reproduce the bug in Dolphin. 4. While it's frozen, switch to the gdb terminal and press Ctrl+Z. 5. When the gdb prompt reappears, enter "thread apply all backtrace". 6. Paste the output here. Thanks.
Qt: 4.8.4 KDE Development Platform: 4.10.2 Dolphin: 2.2 (gdb) thread apply all backtrace Thread 3 (Thread 0x7fffeaa70700 (LWP 8244)): #0 0x0000003043ce99ad in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x000000304c9a3480 in poll (__timeout=-1, __nfds=1, __fds=0x7fffeaa6fd00) at /usr/include/bits/poll2.h:46 #2 qt_safe_poll (fds=0x7fffeaa6fd00, nfds=1, timeout_ms=<optimized out>, retry_eintr=false) at kernel/qcore_unix.cpp:121 #3 0x000000304c955540 in QProcessManager::run (this=0x304ccd5520 <processManager()::processManager>) at io/qprocess_unix.cpp:238 #4 0x000000304c87b95c in QThreadPrivate::start (arg=0x304ccd5520 <processManager()::processManager>) at thread/qthread_unix.cpp:338 #5 0x0000003044407d15 in start_thread (arg=0x7fffeaa70700) at pthread_create.c:308 #6 0x0000003043cf248d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 Thread 2 (Thread 0x7fffeb9f8700 (LWP 8235)): #0 0x0000003043ce99ad in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x0000003046847d24 in g_main_context_poll (priority=2147483647, n_fds=2, fds=0x7fffe4002bb0, timeout=-1, context=0x7fffe40009a0) at gmain.c:3584 #2 g_main_context_iterate (context=context@entry=0x7fffe40009a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3285 #3 0x0000003046847e44 in g_main_context_iteration (context=0x7fffe40009a0, may_block=1) at gmain.c:3351 #4 0x000000304c9a6126 in QEventDispatcherGlib::processEvents (this=0x7fffe40008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #5 0x000000304c97680f in QEventLoop::processEvents (this=this@entry=0x7fffeb9f7cd0, flags=...) at kernel/qeventloop.cpp:149 #6 0x000000304c976a98 in QEventLoop::exec (this=0x7fffeb9f7cd0, flags=...) at kernel/qeventloop.cpp:204 #7 0x000000304c878980 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:542 #8 0x000000304c95703f in QInotifyFileSystemWatcherEngine::run (this=0x8a91d0) at io/qfilesystemwatcher_inotify.cpp:256 #9 0x000000304c87b95c in QThreadPrivate::start (arg=0x8a91d0) at thread/qthread_unix.cpp:338 #10 0x0000003044407d15 in start_thread (arg=0x7fffeb9f8700) at pthread_create.c:308 #11 0x0000003043cf248d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 Thread 1 (Thread 0x7ffff7f9d880 (LWP 8229)): #0 0x0000003043ce99ad in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x0000003046847d24 in g_main_context_poll (priority=2147483647, n_fds=12, fds=0xdc92d0, timeout=15386, context=0x649c00) at gmain.c:3584 #2 g_main_context_iterate (context=context@entry=0x649c00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3285 #3 0x0000003046847e44 in g_main_context_iteration (context=0x649c00, may_block=1) at gmain.c:3351 #4 0x000000304c9a6106 in QEventDispatcherGlib::processEvents (this=0x614570, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #5 0x000000305126a73e in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:207 #6 0x000000304c97680f in QEventLoop::processEvents (this=this@entry=0x7fffffffdb40, flags=...) at kernel/qeventloop.cpp:149 #7 0x000000304c976a98 in QEventLoop::exec (this=0x7fffffffdb40, flags=...) at kernel/qeventloop.cpp:204 #8 0x000000304c97b888 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1218 #9 0x0000003446c4f6d7 in kdemain (argc=1, argv=0x7fffffffddb8) at /usr/src/debug/kde-baseapps-4.10.2/dolphin/src/main.cpp:90 #10 0x0000003043c21a05 in __libc_start_main (main=0x4008a0 <main(int, char**)>, argc=1, ubp_av=0x7fffffffddb8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdda8) at libc-start.c:225 #11 0x00000000004008d1 in _start ()
Created attachment 79464 [details] strace output from dolphin with a link to a missing nfs server in the sidebar
(In reply to comment #12) That backtrace shows no signs of a freeze. Looks like the event loop in the GUI thread is running normally.
(In reply to comment #11) Thanks for trying to solve this issue! > 4. While it's frozen, switch to the gdb terminal and press Ctrl+Z. > 5. When the gdb prompt reappears, enter "thread apply all backtrace". After pressing Ctrl+Z, the gdb prompt never (>1h) reappears. Even after killing Dolphin (Ctrl-Alt-Escape+click), the terminal remains blocked.
This ticket doesn't need "INFO". It just needs someone to fix it. Whoever put the label "NEEDSINFO" or "WAITINGFORINFO" on it, should be kicked out of the KDE organisation, IMHO.
There is no way in the linux kernel to check if network mount is available without waiting for it to be available. As such, it is only possible to avoid the hang with out-of-process calls, as KIO provides. If you are not using KIO to access network mounts, then you are out of luck (and insulting respected KDE developers is no way to get attentention to this kernel problem).
Thank you for closing this bug (voted by 40 people) without solving anything. Don't worry, I will not insult anybody nor try to get attention to this bug anymore: after having waiting several years, I eventually shifted 4 of my business computers from KDE to Gnome because of this bug, and I will do the same for the other ones as soon as I get time. Strangely enough, the problem doesn't exist on Fedora 23 (nor on Fedora 22) file manager with Gnome. I'm happy KDE meets the needs of some, but not ours.
While I see the developers' point, namely that the bug is actually outside Dolphin itself and would be better solved upstream, a more pragmatical approach may nonetheless be relevant. For average users (e.g. any of the 15 people in my team), it does not really matter in which library the bug is actually located: what they see is that Dolphin is frozen and does not work. It would therefore make a lot of sense to develop a temporary workaround within Dolphin until the real bug gets fixed. Keep in mind that Dolphin will freeze even when the user is merely trying to browse the local home: because the Places Panel will try to list the stalled share, Dolphin will freeze. For the last several years, the situation has been that people in my team complain that Dolphin does not work and I have to waste time trying to fix the mess. And it is really a pity because as a result, although everybody agrees on the principles of FOSS, none of them is actually able to run GNU/Linux at home because they don't know how to fix this kind of issues themselves.
(In reply to Christoph Feck from comment #17) > There is no way in the linux kernel to check if network mount is available > without waiting for it to be available. As such, it is only possible to > avoid the hang with out-of-process calls, as KIO provides. If you are not > using KIO to access network mounts, then you are out of luck (and insulting > respected KDE developers is no way to get attentention to this kernel > problem). With people like you (I do not consider you a developer (you don't seem to have much of a resume) and will also never hire you), KDE doesn't need enemies. Please, whoever has control over the KDE project, also kick out this guy for incompetence and/or malice. I agree completely with Fiable.biz and michael.zugaro@college-de-france.fr. The fix for this is *extremely* simple; you just start a thread for every element in "Places" to begin with and concurrently you raise this issue to the LKML explaining how retarded Linux is in its current state, but apparently you lack the intelligence and communication skills to do that. Then, you can point to that if users are still complaining. Those users can then decide to run another kernel, or someone can fork Linux to add the required functionality. Wouldn't that be fun to ask to Linus what kind of idiot he is (if in fact there really is no interface to do this)?