What is locate and mlocate and what means man-db.service?

If I may ask the same question again.
This is my systemd-analyze blame

[limo@lenovo ~]$ systemd-analyze blame
13.541s updatedb.service
 1.580s man-db.service
 1.129s efi.mount
  494ms dev-sda2.device
  388ms firewalld.service
  349ms ldconfig.service
  218ms lvm2-monitor.service
  196ms user@1000.service
  144ms systemd-udev-trigger.service
  137ms systemd-journal-flush.service
  125ms udisks2.service
  102ms systemd-tmpfiles-setup.service
  101ms systemd-journald.service
  101ms upower.service
   79ms systemd-remount-fs.service

Reading around about updatedb.service and man-db.service I found some saying that updatedb.service can be disabled if the user is not using “locate” to find files!

I read this thread at the Arch Linux forums where the user says “So in the absence of a real need for the locate command uninstalling the mlocate package looks like the easy way to work around the problem on my machine.”

As it is something related to booting my system, I will never uninstall something (“uninstalling the mlocate package” as the user said) before hearing from the experts here.

I don’t even know what “mlocate” or “updatedb.service” are!

I am on KDE Plasma, BTRFS, systemd-boot, defaulting to LTS kernel and have the default kernel installed as well. I installed and using Recoll to search for my files by content.

Would you agree with me doing:

yay -Rc mlocate

to save my self all this time it takes for booting?
What about man-db.service?

I would be booting in like 2 or 3 seconds then!

I am just trying to get the most out of my system. (I may sound naughty I know, but I am asking experienced users for permission before I do naughty things)

I read he said there “Edit: After rebooting the machine the boot was very quick with the timers above not running the database updates -”
Is it OK to do so?
What you think?



Joke aside… you do n to need locate if you do not use locate command at all it ha nothing to do with the boot of the system itself… only a service running on boot to update the database for you:


this is from a systems timer mlocate enables if installed:

mlocate enables its timer upon installation. start it manually if you want to use it before reboot. You can also manually run updatedb as root at any time

So in conclusion you can safely uninstall the mlocate package it will not harm anything…

is in the same fashion running as a timer so not every boot:
you can check their status:

[11:30:59]  ➜  ~ » systemctl status man-db.timer   
● man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; preset: disabled)
     Active: active (waiting) since Sun 2022-08-28 10:15:50 CEST; 2h 52min ago
      Until: Sun 2022-08-28 10:15:50 CEST; 2h 52min ago
    Trigger: Sun 2022-08-28 17:31:55 CEST; 4h 23min left
   Triggers: ● man-db.service
       Docs: man:mandb(8)

Aug 28 10:15:50 i3-private systemd[1]: Started Daily man-db regeneration.

[13:08:38]  ➜  ~ » systemctl status man-db.service 
○ man-db.service - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.service; static)
     Active: inactive (dead)
TriggeredBy: ● man-db.timer
       Docs: man:mandb(8)
1 Like

Thanks @joekamprad
This is good news.
Just curious, would it be “wiser” to disable “updatedb.service”? If so, how to?

You said “You can also manually run updatedb as root at any time”
What does it really do? Why would I run it? What if I did not?

remove what you not use is the best… it will not touch the state of it if you may want to use it in the future… you may long time forget about you disable it… or mask it and wonder why the heck it is not working…
I remember adding mlocate to the packages a long time ago … not sure if it has the timer by that time… as usually you will need to update the database manually anyway to find latest changes in case you have a case you need to find the needle in the haystack…

When i start with arch it was what everyone using so i was adding it… could be we remove it from default install anyway… as if you do not know about and/or you do not use it it is doing nothing aside from delay on boot from time to time :wink:

My main search needs I do through Recoll. Would uninstalling mlocate affect Recoll?

as it is a search engine that uses its own database of files you need to have an up to date database if you need to search for files that may changed currently… as an example:

i try to remove all grub stuff and search for leftovers like so:
locate grub

it finds a lot of stuff i want to remove and i want to see if i catched them alls i rerun
locate grub
and if i do not update the database it will show the same files as before also the ones i already removed… but if i run the sudo updatedb it will only show the files i do not catch to remove :wink:

 Dependencies (22)

    antiword (optional) - for msword
    aspell-en (optional) - English stemming support
    catdoc (optional) - for ms excel and powerpoint
    djvulibre (optional) - for djvu
    id3lib (optional) - for mp3 tags support with id3info
    libxslt (optional) - for XML based formats (fb2,etc)
    perl-image-exiftool (optional) - EXIF data from raw files
    poppler (optional) - for pdf
    pstotext (optional) - for postscipt
    python-lxml (optional) - indexing spreadsheets
    python-mutagen (optional) - Audio metadata
    python-pychm (optional) - CHM filter
    unrtf (optional) - for RTF
    unzip (optional) - for the OpenOffice.org documents
    python (make)
    python-setuptools (make)

i do not know this one but mlocate is no dependency and not optional also…

Thanks “Doktor”
So, I will go uninstall and reboot in 2 seconds!
Rebooted! Here it is:

Startup finished in 2.381s (firmware) + 3.359s (loader) + 2.766s (kernel) + 3.145s (userspace) = 11.653s 
graphical.target reached after 3.108s in userspace

Before that it was:

[limo@lenovo ~]$ systemd-analyze
Startup finished in 2.361s (firmware) + 3.373s (loader) + 2.395s (kernel) + 2.790s (userspace) = 10.921s 
graphical.target reached after 2.725s in userspace.
[limo@lenovo ~]$ 


[limo@lenovo ~]$ systemd-analyze blame
517ms dev-sda2.device
406ms firewalld.service
348ms ldconfig.service
286ms user@1000.service
197ms systemd-journal-flush.service
191ms lvm2-monitor.service

Thank you very much Doktor @joekamprad

This service drives me mad because IMO it unnecessarily extends boot time (I remember waiting nearly 1 min on an SSD with 5 GiB per second random read and 6 core CPU) and the task of updating manual database suits better as a pacman post transaction hook instead of boot time.

WOW! That’s too much for an SSD!
After I uninstalled mlocate I cant see as well the man-db.service as you can see from my post above. I do not know how they relate. No techie here!

man-db.service runs only on 1st boot of each day.

I see, that’s why I don’t see it now.
So should I do:

sudo systemctl mask man-db.service

If you do that the service will no longer run, ever. You can change its frequency instead, or disable it and add a pacman hook.
If you don’t care about manuals mask it and forget it.

Honestly I do not know what it does and I do not know if it is needed or not!

It is for updating manual database, the instruction files you access with ie.

man python

I see!
Well, a second or two more in boot is not a big issue.
Thanks for clarifying lots of things for me @mrvictory