Public bug reported:
/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)
** Affects: tracker (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug xenial
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tracker in Ubuntu.
https://bugs.launchpad.net/bugs/1752430
Title:
tracker-miner-apps fails when /usr/local/share/applications is a link
Status in tracker package in Ubuntu:
New
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)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1752430/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
