| Summary: | Launcher hangs on unavailable nfs mount in home directory | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Deepankar Sharma <deepankar.sharma> |
| Component: | Application Launcher (Kickoff) widget | Assignee: | David Edmundson <kde> |
| Status: | CLOSED INTENTIONAL | ||
| Severity: | normal | CC: | plasma-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | 5.5.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Deepankar Sharma
2016-08-20 19:59:37 UTC
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.
|