[TRACKING] New heat problems / battery life crashed - Gnome tracker-miner-fs-3

Framework Laptop 13 Linux
#1

I have a 12th-gen Intel laptop. It works fine. Ubuntu 22.04.

I have always been a bit disappointed in the battery life, but it was OK enough.

About one month ago, this changed. My battery life went to about an hour total. And my machine started running hot with the fan on a lot.

I was blaming Zoom for this (what a crummy app, but I need it for my work.)

Then I caught the machine having heat and battery issues when Zoom had not been started.

My system monitor showed that the daemon tracker-miner-fs-3 is using 5%+ of CPU. I did some research and this seems like a common problem. On my machine, it makes sense:

  1. I often place very large data files on the Desktop to work for a few hours
  2. I have 3 cloud file services running with rclone (dropbox, pcloud, google drive) - I suspect that the tracker-miner may be looking in the cloud files
  3. I currently have 2 of the 1-TB USB Storage modules with large files on them - and THAT seems to be when the problems started

I did a lot of research, and ran these commands:

sudo systemctl --global mask tracker-miner-fs-3.service
sudo systemctl --global mask tracker-xdg-portal-3.service

Reboot and work for 30 minutes - machine is MUCH cooler and fan is off.

I post here if the fix maintains.

I have read that I may need to re-apply the fix after upgrades - therefore, I just included the above in my update script.

I would far rather just use XFCE, but some of my apps work poorly with XFCE (Slack, Zoom, the usual suspects.) Fixing all that is backlogged for a long weekend.

2 Likes
#2

I can’t really help about your battery consumption but one thing I know : better use Zoom on your webbrowser than the app, especially on linux. Give it a try ! Every common controls and even screen sharing works fine and is more optimised !

#3

Thanks @Aurelien_D - I have done both. Both Zoom and Google Meet in browser do cause my fan to run :wink: But I am OK with it.

UPDATE: End of the day and back of machine is barely warm. It has been hot to the touch full time until I implemented my fix.

#4

Don’t have anything to add at this time, but tracking.

#5

I was curious reading this since I don’t remember disabling that service on this machine (11 gen, Fedora 37). It’s running:

$ systemctl --user status tracker-*
â—Ź tracker-miner-fs-3.service - Tracker file system data miner
     Loaded: loaded (/usr/lib/systemd/user/tracker-miner-fs-3.service; disabled; preset: disabled)
    Drop-In: /usr/lib/systemd/user/tracker-.service.d
             └─00-uresourced.conf
     Active: active (running) since Sun 2023-04-16 13:40:28 PDT; 1 day 1h ago
   Main PID: 67220 (tracker-miner-f)
      Tasks: 6 (limit: 18864)
     Memory: 26.0M
        CPU: 4.392s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/tracker-miner-fs-3.service
             └─67220 /usr/libexec/tracker-miner-fs-3

but uses essentially no CPU.

#6

I believe that the cause of too much CPU for that daemon is caused by my combination of multiple cloud file systems via rclone and multiple one terabyte plug-in modules. I can experiment with taking those offline, and in reversing the changes to see what happens. My normal mode for the machine is to have those cloud file systems and those USB drives

As I said above, this is only been going on for about a month. I believe the big change was plugging in the second one terabyte USB drive. But for whatever reason it started using a lot of CPU, my machine was always hot, and the battery life went to about an hour. Since the fixes, all these problems seem to go away.

In addition, that particular module is only used when I do gnome desktop system wide file searches. I never do that. I use other tools.

#7

Did this happen on another similiar setup?

I can imagine search indexing causing escessive heat generation if scanning all connected drives regulary, especially with TBs of data. What a bad idea to have this enabled by default. (Not your fault, but the OS)

#8

@Anachron I have only one laptop that has this problem.

I agree I don’t like it on by default. I will am not super happy with Gnome Desktop - I prefer XFCE, but had a few issues. I will go revisit XFCE.

As I have confessed before, I have 40+ years of UNIX/Linux back end experience. But I have never invested the deep learning others have WRT all the Desktop configurations and tweaks. Some of the side effects on the Desktop system continue to surprise me.

STATUS on Day 2: Yep it’s a fix!
My machine is running much cooler. My fan has only run 2 minutes today. My battery life is back to its normal Framework battery self. (Not great, but OK for me).

Here is the output of % df -h

bluto@atlas:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           6.3G  2.9M  6.3G   1% /run
/dev/nvme0n1p2  938G   45G  846G   5% /
tmpfs            32G  176M   32G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
/dev/nvme0n1p1  511M  5.3M  506M   2% /boot/efi
tmpfs           6.3G  9.1M  6.3G   1% /run/user/1000
/dev/sda1       932G  555G  378G  60% /media/bluto/USB DISK
/dev/sdb1       932G   27G  906G   3% /media/bluto/ONETB
dropbox:        2.1T  538G  1.5T  27% /home/bluto/Dropbox
plan9:          3.1T  4.4M  3.1T   1% /home/bluto/plan9_dropbox
pcloud:         2.0T   25G  2.0T   2% /home/bluto/pcloud

This is my normal system with two of the Framework 1TB Drives (super fast) and several rclone mount points.

All my code is in GitHub repos, so only shows on my local drive. As much of the other file load and history is in cloud drives.

I think searching all that caused the heat/CPU issues.

rclone mount points are not very fast, but the other benefits far out weigh any downsides for my use cases.

#9

I wonder if doing some customization of what should be indexed for search under Settings → Search → Search locations would let you get closer to having the search cake and eating it too by only including locations under Home that you know aren’t crossing into “difficult” mounts. The default is to include all of Home for indexing.

Too bad there’s no simpler “don’t cross mount point” option in there.