You upgraded Fedora and the fans are screaming
You open your laptop after a long weekend and the fans are screaming. The system feels sluggish. You open the system monitor and see tracker-miner-fs eating 100% of one core. You have been waiting for the desktop to become responsive for five minutes. This happens often after a fresh install, a major update, or when you plug in a drive with thousands of files. The process is stuck in a loop, retrying an error without making progress.
What is tracker-miner doing
Tracker is the desktop search indexer. It scans your files to build a database of metadata so you can search for documents, images, and music instantly. Think of it like a librarian cataloging every book in a massive library. If you dump a truckload of new books onto the shelves, the librarian has to work overtime to read every spine and update the catalog. tracker-miner is that librarian.
The indexer runs in three parts. tracker-miner-fs walks the filesystem tree and checks modification times. tracker-extract reads files to pull out metadata like author names, tags, and text content. tracker-store manages the database where that metadata lives.
When tracker-miner gets stuck, it usually means it hit a file it cannot read, a permission error, or a network mount that responds slowly. The process retries the same file over and over. The retry interval is short. On a network mount with high latency, or a file with broken permissions, this creates a tight loop. The CPU usage stays high because the process is busy waiting and retrying, not because it is processing data.
Fedora uses tracker3. The package name is tracker3. The service names are tracker-miner-fs.service, tracker-extract.service, and tracker-store.service. These are user services. They run under your UID. They start when you log in. They stop when you log out.
Disable the indexer
Most users do not need Tracker. The GNOME search integration works fine without it for basic file names. Disabling the service removes the CPU load and the disk I/O. You lose metadata search, such as searching inside PDFs or by image tags. For most workflows, this trade-off is acceptable.
Here is how to check whether the service is currently active and what it is complaining about.
systemctl --user status tracker-miner-fs.service
# WHY: Shows the current state and recent log lines.
# Look for "Active: active (running)" vs "active (exited)".
# The log lines below reveal if it is looping on a specific error.
If the logs show repeated errors, stop and mask the services. Masking prevents the service from starting automatically on login. Masking is safer than disabling because it blocks accidental restarts by other units.
systemctl --user stop tracker-miner-fs.service
# WHY: Stops the process immediately to free CPU.
systemctl --user mask tracker-miner-fs.service
# WHY: Prevents the service from starting automatically on login.
systemctl --user stop tracker-extract.service
# WHY: Stops the metadata extraction worker.
systemctl --user mask tracker-extract.service
# WHY: Prevents the extractor from restarting.
systemctl --user stop tracker-store.service
# WHY: Stops the database backend.
systemctl --user mask tracker-store.service
# WHY: Prevents the store from restarting.
Tracker runs as a user service, not a system service. You must use systemctl --user. Running systemctl mask without --user targets the wrong unit file and will not stop the process. The mask writes a symlink in ~/.config/systemd/user/. This persists across logins.
Mask the services. Reboot is not required, but logging out ensures the desktop session cleans up any lingering handles.
Verify the CPU dropped
Run the status command again to confirm the mask took effect.
systemctl --user status tracker-miner-fs.service
# WHY: Confirms the service is masked and inactive.
# Output should show "Loaded: masked" and "Active: inactive (dead)".
Check the system monitor. The CPU usage should drop immediately. If the spike remains, another process is consuming the core. Check top or htop to identify the new culprit.
Check the CPU graph. If the spike is gone, the mask worked.
Common pitfalls and recovery
Old guides often reference tracker instead of tracker3. Fedora dropped the legacy tracker package years ago. If you see instructions mentioning tracker daemon -s, ignore them. That command does not exist on modern Fedora. The unit names remain tracker-miner-fs.service, but the package is tracker3.
If you try to mask a service that does not exist, you will see an error.
Failed to mask tracker-miner-fs.service: Unit tracker-miner-fs.service not found.
This error means the package is not installed. You do not have the issue. The high CPU is coming from something else.
Network mounts are the most common cause of loops. If you need Tracker but have a network drive causing the problem, exclude the mount point. Edit the config in ~/.config/tracker3/tracker-miner-fs.cfg. Never edit files in /usr/lib/. User configuration goes in ~/.config/.
Here is how to exclude a problematic directory.
[Miner FS]
# WHY: Excludes specific paths from the indexer.
# This stops tracker-miner from hitting permission errors or slow network responses.
# Paths are relative to the user's home directory unless absolute.
Excluded-directories = ".cache" ".local/share/Trash" "/run/media/user/slow-nfs-share"
Read the config key names carefully. A typo in Excluded-directories silently fails and the loop continues. After editing the config, restart the service to apply the changes.
systemctl --user restart tracker-miner-fs.service
# WHY: Reloads the configuration and restarts the walker.
# The service will skip the excluded paths on the next scan.
If you masked the service and later need it, unmask and reset. A corrupted database can cause high CPU even without bad files. Resetting rebuilds the database from scratch.
systemctl --user unmask tracker-miner-fs.service tracker-extract.service tracker-store.service
# WHY: Removes the mask so the services can start again.
tracker3 reset --hard
# WHY: Deletes the existing database and forces a full reindex.
# This clears corruption that might cause loops.
systemctl --user start tracker-miner-fs.service
# WHY: Starts the indexer manually after the reset.
Use journalctl --user -u tracker-miner-fs.service -n 20 to inspect errors after unmasking. The x flag adds explanatory text. The e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
journalctl --user -u tracker-miner-fs.service -n 20
# WHY: Shows the last 20 log lines for the user service.
# Look for "Error" or "Failed" lines.
# Common errors include permission denied or file not found on removed mounts.
Read the config key names carefully. A typo in Excluded-directories silently fails and the loop continues.
When to use masking vs configuration
Use systemctl --user mask when you want to disable Tracker permanently and do not care about desktop search indexing. Use Excluded-directories in the config when you need search indexing for local files but have a specific drive or directory causing the loop. Use tracker3 reset --hard when the database is corrupted and masking does not resolve the underlying metadata issue. Stay on the default configuration when you have a small number of files and the indexer finishes within minutes of login.