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

Solution 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
   

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

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

Solution 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/

View more solutions

Comments

[user2948306]

Additionally, in apt you can use aptitude remove, aptitude why, or aptitude search '?installed ?recommends(mlocate)'. These will all show recommends dependencies, in addition to the requires ones. apt now installs recommended packages by default, so while they are not considered essential, they may well be relied on to provide some very useful sub-function.

[Davidmh]

The problem with updatedb is not CPU or memory, but IO bandwidth. In my case (a system with a great CPU and plenty of memory to spare) it is spinning my hard drive at 5 MB/s for hours, one by one, slowing everything else that depends on that drive. And when I know what I am looking for exactly, they are new-ish files, so locate is not useful because I cannot be sure it is indexed. When the files are older, I go for fzf and a fuzzy search.