How can I update the cache / index of locate? I installed new packages and the files are clearly not yet indexed. So which command do I have to commit, in order for the indexer to trigger?

I'm currently working on debian jessie (testing): with Linux mbpc 3.13-1-amd64 #1 SMP Debian 3.13.7-1 (2014-03-25) x86_64 GNU/Linux

  • If your locate is from the GNU Find Utilities project (which, if you are using Debian Jessie, it probably is), then you can find the project's website and documentation here: gnu.org/software/findutils
    – user6860
    Apr 23, 2018 at 17:48

4 Answers 4


The command is:

sudo updatedb

See man updatedb for more details.

  • 1
    And put it as a cron. Apr 14, 2014 at 8:17
  • 3
    One remark here, this command runs for ~13 minutes on Debian Stretch RC3 and Sata SSD drive, so be patient.
    – Marecky
    Jun 1, 2017 at 20:33
  • 1
    @Marecky The time it takes is highly dependent on the number of files there are on your filesystem. on a new install, it can run in a matter of seconds
    – tbrugere
    Jun 28, 2021 at 13:09
  • but the other answer says this is a bad idea...
    – endolith
    Feb 5, 2023 at 19:11

On OSX this is: sudo /usr/libexec/locate.updatedb

Which can be linked with: sudo ln -s /usr/libexec/locate.updatedb /usr/local/bin/updatedb

Seems silly to have to make a symbolic link for a standard unix command, but there it is.

  • 2
    I confirm that on January 2024 (with OSX 13.6.1) the path is still correct.
    – yannis
    Jan 9 at 13:28

While the answer:

sudo updatedb

is technically correct, it is almost never a good idea to run updatedb on a command line by itself, if there is also a cron job installed. Depending on the Unix flavor the cronjob contains locking provisions and any amount of configuration which is not covered by the standalone updatedb command.

If the locate database needs to be updated frequently, it is definitely worth the effort to determine the proper cron job for a specific host and run it manually.

Depending on the administrator, the cronjob for updatedb may be hidden in various locations. So a simple brute-force attempt to find the cron job would be:

( sudo crontab -l > /tmp/crontab.root;
  ( echo /tmp/crontab.root; ls -1d /etc/*cron* /etc/*cron*/* ) \
  | tr '\n' '\0' \
  | xargs -0 -r -e grep -nH -e updatedb;
  rm -f /tmp/crontab.root
) 2>/dev/null

which shows the following result on one of my Ubuntu systems:

/etc/cron.daily/mlocate:5:[ -x /usr/bin/updatedb.mlocate ] || exit 0
/etc/cron.daily/mlocate:21:flock --nonblock /run/mlocate.daily.lock $IONICE /usr/bin/updatedb.mlocate

The correct command to update the locate database in this case is therefore

sudo /etc/cron.daily/mlocate

A more systematic approach is to determine the package which provides locate and updatedb.

E.g., on an OS with apt/dpkg packaging you can find which flavor of locate is installed with:

dpkg -S locate | grep /bin/

In my case it is:

mlocate: /usr/bin/updatedb.mlocate

To see, which cron job if any is responsible, run:

dpkg -L mlocate | grep cron

Which in my case shows:


To update the database, run the cron job as root:

sudo /etc/cron.daily/mlocate

If there is no cronjob, and updatedb by itself does not work, try finding your installed flavor with:

dpkg -L mlocate | grep /bin/

which returns:



There is yet another approach to run updatedb on a daily basis using a oneshot systemd service named updatedb.service, mlocate-updatedb.service, etc. This service is triggered by a corresponding timer updatedb.timer, mlocate-updatedb.timer. Here is a sample service file, I found in a repository:


Although it just calls ionice -c 3 /usr/bin/updatedb in this case, it still is better to start the service, making sure it is run in the correct environment without the need to double and triple check the service file for changes introduced by the system maintainers during updates:

sudo systemctl start updatedb.service

Besides examining the package file list, checking for a service can be done with a command like:

systemctl list-unit-files | grep 'updatedb\|locate'
  • sudo crontab -l yelds no crontab for root on linux mint. What could be the issue ? Apr 23, 2020 at 13:43
  • 1
    @HenriquedeSousa Usually there is no crontab for root. So it is not an issue. There are either scripts in /etc/cron.monthly, /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, which are exectued as root. Or there are crontab entries in /etc/crontab, /etc/cron.d, where the user can be specified. However, some administrators do add a user crontab for root, so the crontab -l this is just used to make sure.
    – wolfmanx
    Apr 30, 2020 at 16:03
  • 1
    For me (on manjaro) there was no crontab entry for updatedb but had systemd entries instead /usr/lib/systemd/system/updatedb.service, /usr/lib/systemd/system/updatedb.timer so I used sudo systemctl start updatedb. And I assume it is no different from running sudo updatedb Jul 17, 2022 at 6:31
  • @PhaniRithvij Thanks for the info. I have updated my answer accordingly. Your assumption that there is no difference from running sudo updatedb is wrong. Trivially, you have no idea, which updatedb is started, if you do not specify an explicit path name. Other things are scheduling class and provisions to avoid parallel invocations of updatedb. And there is always a chance that an OS update introduces modifications beyond the wildest imagination ;-) So, if you know, what you are doing, go ahead. I usually assume, that I in fact do not know what I am doing.
    – wolfmanx
    Jul 20, 2022 at 13:33
  • On Fedora 36 I did systemctl enable plocate-updatedb.timer.
    – the Hutt
    Dec 15, 2022 at 9:01

The "locate" package usually comes with a cronjob which runs on a daily basis and updates the locate database.

You can run the cronjob manually to enforce an update of the locate database.

On Debian, you can do this:

sudo /etc/cron.daily/locate

Note that this can run a while, depending on the system performance and the amount of files to scan.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .