2018-05-07 Laptop Fan

Every now and then my laptop’s fan would go nuts. It turns out that one of the processes eating 100% of the CPU was `tracker-store`. It indexes stuff. Another thing I noticed was `brltty` with priority -10.

`brltty` is for Braille displays. Luckily, I don’t need it, so I removed it. `apt remove brltty`.

Removing `tracker` will remove `gnome-photos` which I never used by which actually doesn’t look so bad. But I use `feh` to look at images from the terminal and `gimp` to edit them. So I guess I’m good. `apt remove tracker`.

Hot air and ventilators
Cannot stop tracker from tracking
apt remove
#debian ​#haiku

​#Purism ​#Gnome ​#Debian

Comments

(Please contact me if you want to remove your comment.)

OK, back to the good old 100% CPU `tracker-store` process. But this time, if I try to `sudo apt remove tracker`, it tells me:

The following packages will be REMOVED:
  gnome-sushi nautilus nautilus-share pureos-gnome tracker tracker-extract tracker-miner-fs

Why is `pureos-gnome` being removed? It depends on `nautilus`. Gaaah.

Based on some StackExchange info:

some StackExchange info

`gsettings list-schemas|grep Tracker` to find the right schema.

`gsettings list-keys org.freedesktop.Tracker.Miner.Files` to find the right keys.

`gsettings describe org.freedesktop.Tracker.Miner.Files crawling-interval` shows some documentation...

`gsettings set org.freedesktop.Tracker.Miner.Files crawling-interval -2` “disables it entirely”

`gsettings describe org.freedesktop.Tracker.Miner.Files enable-monitors` for more information.

`gsettings set org.freedesktop.Tracker.Miner.Files enable-monitors false` “to completely disable any file monitoring”

`tracker reset --hard` to reclaim disk space.

Alternatively... use the GUI? But the tools mentioned in the answer appear to be not installed. So the command line it is.

alex@melanobombus:~$ gsettings set org.freedesktop.Tracker.Miner.Files enable-monitors false
alex@melanobombus:~$ gsettings set org.freedesktop.Tracker.Miner.Files crawling-interval -2
alex@melanobombus:~$ tracker reset --hard

Although most content indexed by Tracker can be safely reindexed, it can’t be assured that this is the case for all data. Be aware that you may be incurring in a data loss situation, proceed at your own risk.

Are you sure you want to proceed? [y|N]: y
Found 2 PIDs…
  Killed process 1964 — “tracker-extract”
  Killed process 3186 — “tracker-store”
Setting database locations
Checking database directories exist
Checking database version
Checking whether database files exist
Removing all database/storage files
  Removing database:'/home/alex/.cache/tracker/meta.db'
  Removing db-locale file:'/home/alex/.cache/tracker/db-locale.txt'
  Removing journal:'/home/alex/.local/share/tracker/data/tracker-store.journal'
  Removing db-version file:'/home/alex/.cache/tracker/db-version.txt'

– Alex Schroeder 2018-11-23 17:38 UTC

---

Fucker is still going strong.

top - 08:08:07 up 41 min,  1 user,  load average: 1.79, 1.79, 1.46
Tasks: 233 total,   3 running, 230 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.9 us,  2.9 sy, 20.9 ni, 70.2 id,  0.1 wa,  0.0 hi,  1.1 si,  0.0 st
MiB Mem :  15959.6 total,   6117.1 free,   2316.5 used,   7526.0 buff/cache
MiB Swap:   1904.0 total,   1904.0 free,      0.0 used.  13179.1 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 8396 alex      39  19 2701064 180188  58580 R  91.7   1.1  13:13.17 tracker-extract
 2106 alex      20   0   54.9g 236024  12912 S   7.6   1.4   6:01.79 tracker-store

The settings are as described above. This makes me unhappy.

I’m currently using `tracker daemon -k` to kill it whenever the fans start going. Surely there is a better way?

– Alex Schroeder 2018-11-28 07:08 UTC

---

Hello,

i got same problem some times ago and i managed to fix it by cleaning up tracker database, i did toot on mastodon for it and discovered i was not the only one.

entry point to get resolution was to find those traces in my `/var/log/message` :

Cannot initialize database: error in view fts_view: no such table: main.nie:InformationElement_nie:keyword_TEMP (strerror of errno (not necessarily related): Aucun fichier ou dossier de ce type)

through duckduckgo serach i got this :

`tracker-store restart loop gitlab.gnome.org/GNOME/tracker`

i finally fixed it with : `tracker reset --hard`

that resets sqlite dabatase that was corrupted by a preceding version.

– troisiemelobe 2018-11-28 07:24 UTC

troisiemelobe

---

Thanks! For now I’m following @algernon’s advice: `systemctl --user disable tracker-store.service && systemctl --user mask tracker-store.service`

@algernon

As for `/var/log/messages` I find a ton of error messages related to tracker, including the one you mentioned (but timestamped Nov 23 instead of Nov 28), and other messages where it cannot parse this or that file... Yikes!

– Alex Schroeder 2018-11-28 07:48 UTC

---

Recently I woke the laptop from sleep and the fans went on like crazy. Killed all the apps. Still crazy. Logged out. Still crazy. Restarted! Still crazy!? This must be some sort of NSA mishap or what? 😮 I was only able to fix it by turning it off and on again.

The universal fix.

– Alex Schroeder 2019-04-27 09:24 UTC

---

And again. Woke the laptop from sleep, fan is going crazy, load seems minimal. A restart doesn’t help, only a complete power down.

– Alex Schroeder 2020-02-09 10:48 UTC

---

Years later, tracker-extract-3 is making the fans spin and none of the above helped. I uninstalled it, and since nautilus depended on it, it had to go as well. The solution was to install its Cinamon brother, Nemo. Thanks for the suggestion, @asjo@illuminant.asjo.org.

— Alex 2023-10-19

My nemesis is back: `tracker-miner-fs-3`, the most cursed piece of CPU burning software. I definitely know that the cooling fans are working, now. I thought I had this fixed? Apparently I messed up somewhere and the ghoul is back.

This is what I did:

sudo apt remove tracker
sudo killall tracker-extract-3
sudo killall -9 tracker-miner-fs-3
systemctl --user daemon-reload

In hindsight, I should have removed it, then reloaded the user systemd, and see whether that automatically stopped the service?