Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is updatedb necessary at all? I never use locate and my servers tend to have dozens of millions of files which usually makes updatedb to run for a long time and consume I/O needed by MySQL and/or other software.

Can I just remove it from cron and expect everything to work? (by everything I mean usual software found on server: linux, cpanel, mysql, apache, php etc.).

share|improve this question
up vote 8 down vote accepted

Yes you can disable it in the crons or remove the package that provides updatedb. On a Red Hat system you'd go about the steps in determining if anything requires it prior to removal.

  1. First find out where the program is located on disk.

    $ type updatedb
    updatedb is /usr/bin/updatedb
  2. Next find out what package provides updatedb.

    $ rpm -qf /usr/bin/updatedb
  3. See if anything requires mlocate.

    $ rpm -q --whatrequires mlocate
    no package requires mlocate
  4. Nothing requires it so you can remove the package.

    $ yum remove mlocate
share|improve this answer

You can disable the scanning of directories that has many files (/var/www for example) by editing the /etc/updatedb.conf configuration file. If you really want to disable it, then just remove the cronjob.

share|improve this answer

Remove it using your package manager, if another package uses it, you will know, since it has to depend on it (package dependency).

I have a server with Nginx, php-fpm and mysql, and it works beautifully without updatedb.

share|improve this answer

Im not going to far out on a limb by saying this, but more than likely it is not updatedb that is causing your problems. Probably something else that you dont want, either a back-up application that you have not configured to your 'liking' or some security issue with your profile/systems group structure.

Another case in which it would seem that the systems memory allocation is working against the user is the scenario when one 'unknowing stacking virtual file systems'. And that is booger of problem. A 'virtual ill-logic bomb' so to speak.

It quite frequently happens to USB drives formatted in fat32 on an ext 4 system who are then transfered to zfs systems that are improperly set up with the csh shell as the man login shell. It creates the virtual recursion of "Read-File only USB file system" problem on the disk and formats/mounts the drive to vFat from fat32, which in turn creates a bad blocks sector, and extracts (virtually moves) a directory up to its parent directories level, which causes the infinite loop! The directory isn't physically at the parent's level of hierarchy. The Syntax of the csh causes is the cause of this. *NOTE: The drive is read only on all systems but a zfs c-shell login system.

To completely disable updatedb could create ill-logic in reference to memory-allocation and 'the roll back effect'.. If you have ever had a roll back when you didnt want it, you know what I mean when two hours worth of command line scripting is Fubar-ed because you didn't allocate your your job processing into memory.

Now if you have two or more physical processors (e.g. dual core or more), and ddr3 ram, then your fine. As long as your not running heavy graphics, in which case if that powerload is causing your problems, updatedb would be last on your list. If you are trying to disguise your movements to the system for some reason then there is other ways to go about it rather than disabling updatedb, and in fact updatedb would would solidify your actions that 'nothing happen' as far the disguise to your system.

Quite frankly based on the size of the binary file /usr/bin/updatedb and considering the architecture of signal/system communication with-in the OS and that Bash is 10 times the size of is reciprocally linked shell dash or ash the asyncronous call is very inexpensive on the system.

If you are logged into the shell running sequential scripts you've written, and you are an administrator (e.g. sudo), running the following command:

~$ sudo bash
:~# ./script.sh

Then you probably want to create a local variable within your script (updatedb needs system priviledges, AKA root/sudo/wheel), e.g.:

#! /bin/sh
# Create local variables

echo "Beginning Execution of sequence "

In which case the sequence is using STDOUT/STDIN from other shell scripts that you have written and are executing as variables with in your main script or say you have a personal or business admin package set up where you upload/download/port from cdrom or usb or whatever, that is extremely large and have personal installation scripts for them, YOU WANT TO KEEP updatedb. When the terminal shell is open, that is your main application instance. Other applications can/do run asyncronously but updatedb is one of the least expensive in terms of overall system/computing demand. Many times, especially with on the lxdm Desk Enviro's and the Lxterm (that thing is super fast), but not solely; with out adding updatedb to my scripts, the system has shot me errors that the files don't exist or that something screwy had happened. And Im like WHAT!

The shell is faster than system that it administers I guarantee you that!

In which case you would then call updatedb variable to lock the previous sequence into memory, as shown

echo "Updating local database "


echo "Exiting script two "


Do you see what Im saying? If you ask this because you are running execution speed tests i.e. Andrew Tanenbaum style than have at it. Other wise use the tool to your advantage.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.