Re: [Tracker] No contents indexing taking place

On Thu, 2012-03-01 at 19:10 +0000, Karl Relton wrote:
On Thu, 2012-03-01 at 15:31 +0000, Martyn Russell wrote:
On 01/03/12 10:47, Karl Relton wrote:
That certainly looks like a broken install.

Out of interest, can you start the tracker-extract process manually and
does it fix the issue?

    /usr/libexec/tracker-extract -v 3

Yes (for me it is in /usr/lib/tracker/tracker-extract). Starting this
manually then the file does get indexed, and found in subsequent


Presumably this file is in place too and points to the right binary:


Yes - this file is in place and points correctly
to /usr/lib/tracker/tracker-extract

NOTE: The above two locations for tracker-extract are *NOT* the same. 
This looks quite suspicious to me.

I would wager that running these two commands outputs different results:

   /usr/libexec/tracker-extract -V
   /usr/lib/tracker/tracker-extract -V

In any case, I wouldn't expect both locations to have that binary. So it 
certainly looks like you need to clean your $prefix and re-make install.

laptop1:~> /usr/libexec/tracker/tracker-extract -V
/usr/libexec/tracker/tracker-extract: Command not found.

laptop1:~> /usr/lib/tracker/tracker-extract -V

Tracker 0.12.10

This program is free software and comes without any warranty.
It is licensed under version 2 or later of the General Public License
which can be viewed at:

Looks like Ubuntu compiles their packages with --libexecdir=/usr/lib,
though at the moment I cannot see where they set this.

Note the location in my .service file does match where the executable
has been installed to. Remember also that tracker-miner-fs seems to be
able to start tracker-store okay (presumably via
dbus /usr/share/dbus-1/services/org.freedesktop.Tracker1.service, which
points to /usr/lib/tracker/tracker-store), so I think the packages are
built consistently.


I've found out some more - the tracker-extract process is in fact being
started (by dbus), but for some reason the initial call to it is getting
an unknown interface error. Subsequent calls to it (while it is still
running), will work however.

By watching what processes are running, I can see the tracker-extract
process start, and then gracefully exit 30 seconds later. The first file
change that resulted in its invocation doesn't get any indexing done
(because it gets the unknown interface error), but if I change the file
again (or another file) before the 30 second inactivity timeout then
indexing will occur with respect to that second change.

So the problem seems to be that first call. Not sure if it is an error
(or timeout) in dbus, or an error in the way
tracker-miner-fs/tracker-extract are trying to interact with each other.

Could it be that tracker-extract is taking too long to register the
interface (make it available) in dbus?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]