Ah, it does appear that trackerd is attempting to do some SQLite locking on a file that is (in my case) on an NFS home directory. It repeatedly fails (fcntl returns EAGAIN), and it seems that trackerd is spinning there and thus not responding to dbus RPCs.
One work-around (besides 'sudo apt-get remove tracker') is to symlink the directories that trackerd needs into a local directory. e.g. $ mkdir -p /var/tmp/${USER}-tracker/{cache,local} $ killall -9 trackerd $ cd ~/.cache && rm -rf tracker && ln -s /var/tmp/${USER}-tracker/cache $ cd ~/.local/share && rm -rf tracker && ln -s /var/tmp/${USER}-tracker/local You may need to logout and in again. Obviously, this blows away any existing tracker database you might have. Not sure if this should be assigned to tracker or gtk. On the one hand, why should gtk be talking to tracker at all for a file dialog? On the other, trackerd is not behaving in an NFS friendly fashion. Adding tracker and maybe someone there will triage more completely. ** Also affects: tracker (Ubuntu) Importance: Undecided Status: New ** Summary changed: - gnome or gtk file dialog is terribly slow + gtk file dialog blocks on trackerd (via dbus) for 25s for users with NFS homedirs -- gtk file dialog blocks on trackerd (via dbus) for 25s for users with NFS homedirs https://bugs.launchpad.net/bugs/218230 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs