For several weeks, my system was constantly overheating. I tracked the issue down to the updatedb process from the plocate package, which was causing permanent high CPU load. After uninstalling plocate, the CPU temperatures went back to normal immediately. My System is a new (3 month old) Mini PC, Ryzen 7730 U, 1 GB SATA NVME SSD + 1 Samsung 250GB SATA SSD. Running on Fedora 44 KDE Plasma. Problem was on Plasma 6.6 and was still the same with actual 6.7.
I run plocate on all my installed distros, including F44. updatedb only runs when I initiate it.
Hm, nice. But for me it was just running all the time. I did not start it, i did not even know it exists until i spottet the problem. Im new to Linux Desktop, but i have 30+ years experience to Windows (so im not a complete Computer noob). AI told me that this is a known problem. So after it made so much problems to me im just reporting it. The differnce is dramatic. Before 85 to 90 degree (up to system shutdown) to just chilling 40 to 50 degrees after uninstalling. For me thats a major bug… 
Edited … see below.
I stand corrected …
Yes, updatedb runs periodically on its own. It is typically managed by a systemd timer named plocate-updatedb.timer.
Frequency of Updates
Daily Updates: The plocate-updatedb.timer is configured to update the database every day.
Doing a search on my F44, it does seem systemd is configured for services and automatic updates. I have never noticed this before
locate updatedb
/etc/updatedb.conf
/etc/systemd/system/timers.target.wants/plocate-updatedb.timer
/usr/bin/updatedb
/usr/lib/systemd/system/plocate-updatedb.service
/usr/lib/systemd/system/plocate-updatedb.timer
Further info … it’s set to run in another 1hr50m
systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2026-07-01 00:00:00 EDT 1h 13min Tue 2026-06-30 07:15:46 EDT - unbound-anchor.timer unbound-anchor.service
Wed 2026-07-01 00:29:05 EDT 1h 42min Tue 2026-06-30 07:40:06 EDT - logrotate.timer logrotate.service
Wed 2026-07-01 00:36:54 EDT 1h 50min Tue 2026-06-30 07:45:16 EDT - plocate-updatedb.timer plocate-updatedb.service
Wed 2026-07-01 01:40:36 EDT 2h 54min Tue 2026-06-30 22:24:14 EDT 22min ago dnf-makecache.timer dnf-makecache.service
Wed 2026-07-01 22:08:16 EDT 23h Tue 2026-06-30 22:08:16 EDT 38min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2026-07-05 01:00:00 EDT 4 days Sun 2026-06-28 01:01:01 EDT - raid-check.timer raid-check.service
Mon 2026-07-06 00:14:20 EDT 5 days Mon 2026-06-29 07:07:04 EDT - fstrim.timer fstrim.service
Simple enough to stop/disable it, which I wish you would have done to see if the runaway would have stopped.
sudo systemctl stop plocate-updatedb.timer
sudo systemctl disable plocate-updatedb.timer
Hm @ Larry, i think you do not understand my post. Thx for your efforts to solve the problem. The thing is i have allready solved it. Maybe not the best solution but i solved it. It tooks me a couple of weeks, but now the system is fine. (I don`t need locate). The point is the following, sure im able to solve this after a couple of weeks. But what about the average user? (im not average because i have 30+ years of experience). So what, 100dreds of videos announcing Linux as an alternative to Windows. I love it, because of the known Windows forces. But, there is a great difference between what the videos are promising and the reality. My post is not about getting help ( I fixed it already). It is about a problem. And overheating with standard installation is a problem.
I do not think that the problem will be replicated on all machines or installs.
If you make a bug report at bugzilla.redhat.com the maintainer may be able to dive into it and fix it for affected systems.
Your posts and solutions here help everyone find and fix the issue too.
I tried, getting error messages after error messages even to login, so i gave up. ( Funny thing, i wrote this to my AI, the answer was, post this in the this forum, because the bugzilla system is known for its bugs
to login to bugzilla, use the Fedora Accounts SSO, accessible from the top right corner of the screen.
Why do we have like 400 login options? No idea!
Ok, this is going to far. i have reported my issue. Care about or dont care about. For me it is a serious problem. You are telling me now issues about form or places where to post. I dont care. I just want to run Linux, i love it. And i would love to make Linux available for everbody. But things have to run!!!
It would be nice if AI would provide the source of that piece of information.
According to bugzilla there as a problem in very special cases with a very specific type of file system. For most of us, updatedb runs very quickly depending on the speed of the disk units and the amount of data stored.
Thats nice, congrats! it would be nice if you can provide the source of that piece of information.
FYI: I’ve never had problems with updatedb, but noticed the spin-ups recently. It might even be that I had removed it long ago and it got reinstalled as a weak dependency on upgrade or such.
For the first user experience, it would be good to know whether plocate is installed and the updatedb service enabled by default on a standard Workstation. (I haven’t checked.)
It may also be that something changed about the handling of missed timer events - that is, if the timer says “by 10am each day”, and you do not turn on your box one day, then turn it on at 9am the day after, you might get the “missed” run right after start-up and the regular one at 10am.
And yes, I do see overheating for the time of the run, but there’s also a heat wave going on.
By the fact that plocate-updatedb.timer is enabled by default, and therefore is widely used, and the lack of bugzilla reports.
Got me i already asumed that the original post was based on User experience And it is nice to hear that the updatedb program is running so nice for alot of people. But it does not change alot for me. I haven`t made this post because of a simple problem. After i installed Linux Desktop 3 month ago i had 100dred little problems to make the system run in a way i like. But this is different. The overheating was a serious issue, wich made me tweaking the bios to fix TDP and fan speed and other things. It costs me alot of time and nervs. Finaly deinstalling a preinstalled program and see it solves all my overheating problems is strange. This should not happen.
It has happened in the past for a new or uncommon configuration that required editing the list of filesystems to be ignored in updatedb.conf (https://bugzilla.redhat.com/show_bug.cgi?id=2033216. Such issues probably won’t be fixed without a proper bug report to the upstream developers. Posting to this forum without the detail needed to understand the issue will not result in changes. Linux has become enormously complex and it is all too easy to end up with a broken system. The information users need is often hidden in old bug reports. I do question the wisdom of using the PRUNEFS list rather than a list of “acceptable” filesystems. The latter would avoid a few (apparently rare) potential problems like the one you encountered, but some configurations would end up with incomplete databases potentially affecting many users.
On my work PC where I have hundred of thousands of files, updatedb can in fact become a hassle and I have disabled it. That said, it should not take weeks to find that it is the culprit. Just starting up the system monitor show it.
It is however true that per default KDE system monitor only shows user processes, so no updatedb, but a simple search for “linux which process is hogging my pc” will give you all the info you need to track it down. A second search for “can I disable updatedb” will tell you that you can, and show you how to do it.
I wonder if “30 years of experience” with Windows is always an asset, as some things are done differently in Linux. I.e. the graphical tools are not the primary way to interact with system services.
I agree. The list of acceptable file system types would be way shorter. It would probably be
- btrfs
- ext4
- vfat
- xfs
- maybe ntfs