Can I just disable updatedb?

Question

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.).

Answer 1

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
   mlocate-0.26-3.fc19.x86_64
   

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
   

Answer 2

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.

Answer 3

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.

Answer 4

At least in ArchLinux, it appears that man-db.timer and updatedb.timer are enabled by default (ie: the following files exist), but there is no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. [...] (output from systemctl enable {man-,update}db.timer).

These are the symbolic links that are present in the filesystem:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
/usr/lib/systemd/system/multi-user.target.wants/updatedb.timer

It should be a matter of simply removing them.
However, they would be recreated at each re/installation/upgrade of man-db, mlocate packages, respectively.

For ArchLinux, a possible workaround is to have a hook for pacman to remove them.
However, it would remove them at each such event, even if you want them enabled across upgrades.
You could, in that case, disable the hook when wanting the timer enabled.
But, enabling the timer would take effect only at re/installation/upgrade of the package, as there is no configured section in the default .timer unit files to directly systemctl enable the timers.
A manual ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timer or ln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timer command would be needed to enable the timer/s, and removing the link/s to disable them.

You could have overriding custom units /etc/systemd/system/{man-,update}db.timer, providing WantedBy=multi-user.target in the [Install] section to allow systemtl enable|disable, but the links /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timer would still be created on re/installation/upgrade, effectively reenabling the .timers.

You could also run systemctl mask man-db.timer updatedb.timer to mask the timers.
Even if it would still be possible to manually run systemctl start man-db.service updatedb.service to start the corresponding services, you wouldn't be able to manually start the timers, for whatever reason the user would find themselves wanting/needing to do so.
This workaround does not allow having overriding custom /etc/systemd/system/{man-,update}db.timer unit files present if desired/needed, as systemd needs to replace them with a symbolic link to /dev/null to signify a masked unit.

Masking appears to be the least intrusive solution.
I prefer manually removing /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timer after each upgrade, and having overriding unit files /etc/systemd/system/{man-,update}db.timer having an [Install] section with WantedBy=multi-user.target to enable manual systemctl enabling/disabling.

Unfortunately, there is no simple work-around this, that at least, I can think of, at this time.
This assumes that the packages man-db, mlocate are wanted/needed to be kept installed in the system: removing them would not be a desired/useful solution.

Also see this: https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/

Answer 5

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
UPD="updatedb"

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 "

$UPD

echo "Exiting script two "

exit

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.