I’ve been downloading some lecture videos from my university from youtube, and noticed unusually high CPU usage during that process. Turns out, tracker-miner-fs-3 and tracker-extract-3 together were keeping 1-2 CPU cores busy … I am using youtube-dl which crates intermediary files for each fragment of the download, so I assume that’s what’s keeping tracker busy.

However, due to security and privacy concerns, I have turned off Search / indexing of $HOME/Downloads in GNOME Settings, which should prevent tracker from looking for files in the Downloads folder at all. Does tracker 3 no longer respect those settings? I can think of no other reason for its high CPU usage, since my PC was idle other than those video downloads …

Additionally, this activity seems to crash tracker-extract-3 regularly, since ABRT is accumulating crash reports for it (24 crashes and counting).

2 Likes

Can you see what it’s doing with strace?

1 Like

Check this:

gsettings list-recursively \
| grep -i -e "tracker.*ignored-dir" -e "tracker.*index-.*dir"

This is the output of the gsettings query:

$ gsettings list-recursively | grep -i -e "tracker.*ignored-dir" -e "tracker.*index-.*dir"
org.freedesktop.Tracker3.Miner.Files index-single-directories ['$HOME', '&DOWNLOAD']
org.freedesktop.Tracker3.Miner.Files index-recursive-directories ['&DOCUMENTS', '&MUSIC', '&PICTURES', '&VIDEOS', '/home/deca/University']
org.freedesktop.Tracker3.Miner.Files ignored-directories ['po', 'CVS', 'core-dumps', 'lost+found']
org.freedesktop.Tracker3.Miner.Files ignored-directories-with-content ['.trackerignore', '.git', '.hg', '.nomedia']
org.freedesktop.Tracker.Miner.Files index-single-directories ['$HOME', '&DOWNLOAD']
org.freedesktop.Tracker.Miner.Files ignored-directories ['po', 'CVS', 'core-dumps', 'lost+found']
org.freedesktop.Tracker.Miner.Files index-recursive-directories ['&DOCUMENTS', '&MUSIC', '&PICTURES', '&VIDEOS', '/home/deca/University']
org.freedesktop.Tracker.Miner.Files ignored-directories-with-content ['.trackerignore', '.git', '.hg', '.nomedia']

This is what strace shows for tracker-miner-fs-3 (many of those in a short time, file name “redacted” by me):

statx(AT_FDCWD, "$FILENAME", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0664, stx_size=40629933, ...}) = 0

This does indeed look like tracker is indexing the Downloads folder, despite the GNOME Settings GUI showing that this is turned off:

Turning this setting for Downloads folder on and off again has no effect on the gsettings values. Looks like the tracker / tracker 3 / gnome-settings-center don’t talk to each other anymore :slight_smile:

1 Like

Can you file a bug and propose it as prioritized, please?

1 Like

Done: https://bugzilla.redhat.com/show_bug.cgi?id=1900227

1 Like

It looks like you have installed both old and new tracker packages.
I guess you should remove the old one:

sudo dnf remove tracker

And exclude downloads from indexing:

gsettings set org.freedesktop.Tracker3.Miner.Files \
    index-single-directories "['\$HOME']"

I’ve been able to remove the “old” tracker packages without issues, looks like the default package now set no longer requires them. They were installed because I upgraded from fedora 32.

However, now GNOME Settings doesn’t let me change Search locations at all. Looks like it expects the old tracker 2 GSettings keys to be present, which explains why it doesn’t affect tracker 3.

Huh. Why are they packaged to coexist?

@decathorpe, you can edit index locations with gsettings or dconf-editor as noted above to exclude the download directory from indexing.

@mattdm, it seems that some packages still depend on it:

> sudo dnf -q repoquery --whatrequires tracker-miners
gnome-documents-0:3.34.0-4.fc33.x86_64
gnome-photos-0:3.38.0-1.fc33.x86_64

IIRC, they were packaged separately because not all GNOME components finished the transition to tracker 3 in time for GNOME 3.38, so both versions needed to be shipped with fedora 34.

you can edit index locations with gsettings or dconf-editor as noted above to exclude the download directory from indexing.

Yeah, sure, I’ve done that now. Still the default UI for this is broken …

Also, indexing Downloads by default sounds like a bad idea. I definitely remember discussion about turning this off by default for security reasons, but maybe that was never actually implemented :confused:

3 Likes