tracker-miner-apps fails when /usr/local/share/applications is a link

Bug #1752430 reported by Jeff Ebert
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tracker (Ubuntu)
New
Undecided
Unassigned

Bug Description

/usr/local/share/applications is a symbolic link on one of my systems because I am using xstow to manage packages in /usr/local. There are valid .desktop files within this linked directory, however.

tracker-miner-apps cannot parse this file/link/directory, so it keeps trying forever with high CPU usage, and spewing error messages to syslog.

Feb 28 12:55:25 gallium gnome-session[30827]: (tracker-miner-apps:30995): Tracker-WARNING **: Couldn't properly parse desktop file 'file:///usr/local/share/applications': 'Couldn't load desktop file:'/usr/local/share/applications''
Feb 28 12:55:25 gallium gnome-session[30827]: message repeated 40 times: [ (tracker-miner-apps:30995): Tracker-WARNING **: Couldn't properly parse desktop file 'file:///usr/local/share/applications': 'Couldn't load desktop file:'/usr/local/share/applications'']

I worked around the problem by making /usr/local/share/applications and directory containing symbolic links to .desktop files within the stowed packages. This is what it looks like now:

jeffrey@gallium:/usr/local/share/applications$ ls -l
total 20
-rw-r--r-- 1 root root 13 Feb 25 20:27 mimeinfo.cache
lrwxrwxrwx 1 root root 61 Feb 28 13:14 thinlinc-setup.desktop -> ../../stow/thinlinc/share/applications/thinlinc-setup.desktop
lrwxrwxrwx 1 root root 65 Feb 28 13:14 thinlinc-webaccess.desktop -> ../../stow/thinlinc/share/applications/thinlinc-webaccess.desktop
lrwxrwxrwx 1 root root 62 Feb 28 13:14 thinlinc-webadm.desktop -> ../../stow/thinlinc/share/applications/thinlinc-webadm.desktop
lrwxrwxrwx 1 root root 75 Feb 28 13:12 vncviewer.desktop -> ../../stow/tigervnc-Linux-x86_64-1.6.0/share/applications/vncviewer.desktop

After this change tracker-miner-apps seems to be happy.

More generally, it's bad and wrong that an indexer can peg the CPU when it has a bug. It should limit rescan attempts to a certain number and then put them on a queue to check infrequently. Would it be just as aggressive if I created a bad .desktop file? An indexer should be as tolerant as possible of bad files, IMO.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: tracker-miner-fs 1.6.2-0ubuntu1.1
ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98
Uname: Linux 4.4.0-116-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
Date: Wed Feb 28 13:26:36 2018
InstallationDate: Installed on 2015-11-19 (832 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
JournalErrors: -- No entries --
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: tracker
UpgradeStatus: Upgraded to xenial on 2016-09-17 (528 days ago)

Revision history for this message
Jeff Ebert (jeffrey-ebertland) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.