I have a nfs mount in my home directory that is periodically unavailable. When the mount is unavailable, trying to open the launcher by clicking the button on the panel yields an unresponsive outline of the launcher that persists for a while before timing out. At no point can I actually click on any items in the launcher. Reproducible: Always Steps to Reproduce: 1. Create a nfs mount in home directory and mount the remote nfs folder 2. Bring down all network interfaces so that the mount is unusable 3. Click on the launcher button to open it Actual Results: Unresponsive outline of the launcher shows up Expected Results: Launcher shows up immediately
If our process locks up in the kernel's file system driver there's nothing we can do about it.
I have a few questions about this - 1. What information is the launcher reading for disk on mouse click? 2. What directories does it hit? 3. Is the launcher also doing some writes? 4. Would it be possible to move the read into an async read with a timeout? Ie launcher gets shown regardless with some information missing, and then when the async read callback happens the information from that callback is used to update the launcher if its still open. 5. A more meta question is whether it is a good idea to read from disk in the hot path of a UI event handler in the first place? Should the information from disk be maintained using a different mechanism ? Ie maybe a separate thread that either polls for this information, or even better something based on inotify / notifications that maintains this information in an event driven way.
Run 1 and 2: "strace plasmashell" to see a log of all kernel calls strace -e open to see only open calls 3: maybe, to sync log of recently accessed files. That's in an SQLiteDB - which can be a problem on NFS. If so you can try turning that off in system settings -> desktop behavior -> activities -> privacy Let me know if that does anything. 4: No. System calls are expected to return. Does "ls ~" return instantly when locked up?
I found the offending syscall, it was a lstat. Here is the output from strace, last column shows time spent inside the call. -> lstat("/home/dman/mounts/nas/data/lect4.mp4", 0x7fffffffd3e0) = -1 EHOSTDOWN (Host is down) <9.997394> I suspect that lstat is being called on recently accessed files? ls blocks too in this case.
>I suspect that lstat is being called on recently accessed files? Seems so. In any case, you've shown it's locking in the kernel. FuseNFS might help your case.