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
Desktop Bugs, which is subscribed to gtk+2.0 in ubuntu.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
