How to start updatedb.timer?

I am a newcomer to manjaro, a refugee from the redhat/fedora world. Things are somewhat different here.
I installed mlocate via pamac. What I can’t figure out is how to start regular updates.

[asok log]# systemctl status updatedb
○ updatedb.service - Update locate database
     Loaded: loaded (/usr/lib/systemd/system/updatedb.service; static)
     Active: inactive (dead)
TriggeredBy: ○ updatedb.timer
[asok log]# systemctl status updatedb.timer
○ updatedb.timer - Daily locate database update
     Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● updatedb.service
[asok log]# systemctl enable updatedb.timer
The unit files have 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.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

A similar service, man-db looks OK:

[asok log]# systemctl status man-db.timer
● man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; enabled; preset: disabled)
     Active: active (waiting) since Tue 2022-11-22 17:57:14 UTC; 5 days ago
      Until: Tue 2022-11-22 17:57:14 UTC; 5 days ago
    Trigger: Mon 2022-11-28 04:34:07 UTC; 8h left
   Triggers: ● man-db.service
       Docs: man:mandb(8)

Nov 22 17:57:14 asok systemd[1]: Started Daily man-db regeneration.

What am I missing?

It will run by itself in about 8 hours.

But you can kick it off with sudo systemctl start man-db.timer.

1 Like

Thanks, though I was asking about updatedb.timer :wink: Anyway, I started the service:

[asok log]# systemctl start updatedb.timer
[asok log]# systemctl status updatedb.timer
● updatedb.timer - Daily locate database update
     Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static)
     Active: active (waiting) since Sun 2022-11-27 21:01:48 UTC; 8s ago
      Until: Sun 2022-11-27 21:01:48 UTC; 8s ago
    Trigger: Mon 2022-11-28 01:42:24 UTC; 4h 40min left
   Triggers: ● updatedb.service

Nov 27 21:01:48 asok systemd[1]: Started Daily locate database update.

The difference is that updatedb.timer shows static, while man-db.timer status shows enabled. Just curious, why? Does static mean the service is always enabled?

Good question. I’m not sure, but at least you got your first database update it looks like.

May be a good moment to switch to a better locate. :slightly_smiling_face:

You manually started it, but when you shut down, it will be stopped and won’t be running anymore upon the next boot. The command to correctly start a systemd timer or service and make sure it remains enabled is… :arrow_down:

sudo systemctl enable --now name-of-service-or-timer

That said however, it should normally already have been enabled when you installed the package, but that does not mean that updatedb will be running right away. It’s a process that takes up quite a bit of CPU cycles — especially on older and slower hardware with fewer cores — and that’s why it has a systemd timer, i.e. it runs only once a day, be it at midnight or, if the machine is down at midnight, upon the next boot.

First of all, welcome to the forum :+1:

As you can read from those outputs:

  • “Active: inactive (dead)” means the unit is not activated/run (yet) by systemd.
  • In updatedb.timer, you see “Triggers: ● updatedb.service”, which means you don’t need to manually enable/start the “updatedb.service” if the timer unit is enabled.
  • In updatedb.timer, you see “Active: inactive (dead)” which means it is not running yet.
  • If a unit shows “static” in it’s “Loaded” line, it means the unit is missing an “Install” section telling systemd how to enable the unit. That’s why systemd shows you the hint:
    The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
    Alias= settings in the [Install] section, and DefaultInstance= for template
    This means they are not meant to be enabled using systemctl.

See the hint from systemd i mentioned above :wink:

  • The easiest and proper way is to create a “drop-in” config that modifies the configuration of the unit you want, without touching the files provided by the maintainers/developers.
    In this case you need to create the drop-in file under /etc/systemd/system/updatedb.timer.d , you can name it as you like but it needs to have a .conf extension.
    (You need to create the directory first if it doesn’t exist yet, which is normal)
  • Because using drop-in files to “override” unit configurations is so common and preferred way, systemd makes it easy for the admin to perform that action.
    You can issue the following command which will open a terminal editor (vim?) with a temporary file and instructions embedded and will create the proper file when you save and exit it.
    sudo systemctl edit updatedb.timer

So now we know what is missing, lets try to figure out why the package has not done so yet…
In the ‘PKGBUILD’ of the mlocate-git version, which is same package just the development version, it shows these lines at end:

install -d "$pkgdir/usr/lib/systemd/system/"
ln -s "../updatedb.timer" "$pkgdir/usr/lib/systemd/system/"

Which means the developer choose to install the timer manually as a vendor.
:warning: (That symbolic link is missing from the regular mlocate package, see it’s files listing)

To translate that and fix it for you, we need to put this inside the drop-in file mentioned above:


Followed by:

  1. Checking/modifying /etc/updatedb.conf to make sure it is configured as needed.
    (Maybe this is the reason it is not enabled by default by the package maintainer/developer)
  2. To check that our drop-in file has no errors:
    systemctl daemon-reload
    systemd-analyze verify updatedb.timer
    • To check that our drop-in file is used:
      systemctl cat updatedb.timer
  3. To start and allow it to be started at boot:
    systemctl enable --now updatedb.timer

Now the timer will be active and run the service when it should, even after a reboot…

1 Like

No, a link to enable the timer is part of the normal package (mlocate version 0.26.git.20170220-7). The repo package uses the more correct “” instead of the “”. Since the package installs a link, it starts on the next boot. However, the timer can be started manually if it is needed earlier than the next boot.

There is no need to edit the timer to create a drop-in. The timer will start eventually.

The timer is not enabled, so it will never start on it’s own without a reboot in that case :wink:

A special target unit that sets up all timer units (see systemd.timer(5) for details) that shall be active after boot.

It is recommended that timer units installed by applications get pulled in via Wants= dependencies from this unit. This is best configured via in the timer unit’s [Install] section.

Note the end of that last line :wink:

No. The timer is enabled. The timer has a link to


Check the pacman -Ql mlocate command, if you have mlocate installed.

To “enable” a timer or a service means only to create a link to a target.wants folder. You don’t need to use systemctl enable for this. But if you want to use systemctl you need to specify the target you want. But it is not needed if you use ln -s to enable a service or timer.

There is still no need to edit this timer file.

No i don’t have it installed, i just checked the file listing of the package via the GUI. :woman_shrugging:
And just trying to help him with my knowledge of systemd so far :wink:

If it starts after a boot for him, then you’re correct…
It won’t hurt anyway if he does create the drop-in…

Yes, and it would be even better if the Arch maintainer would at it to the timer file.

The problem with manually linking a file to a target.wants folder is that systemclt status ... will not show it, if it is not mentioned in the timer or service file. Instead, it shows it as static, wich is not very useful.

You could use pacman -Fl mlocate (You might need to update the list with pacman -Fy first). But this is basically what pamac does. And it really should show usr/lib/systemd/system/

Thanks, but i dont have the habbit of installing programs that i don’t use just to help people :slight_smile:

From the man page of pacman:

-F, --files
           Query the files database. This operation allows you to look for packages owning certain files or display files owned by certain
           packages. Only packages that are part of your sync databases are searched. See File Options below.

It will not install it. It just lists the files this package contains. The -Fl command is like -Ql but queries the repo database, instead of your database of local installed packages.

Oh ok was reading without thinking because:

The pamac GUI in this case, which should have showed it also i guess…

Which it indeed does…

Install SystemdGenie
and look, what systemd is working on.
updatedb.timer is waiting all the time until its triggered. static.
sudo systemctl status updatedb.timer


Thanks for explanations. I ended up installing plocate. It is REALLY fast. A 100MB database search:

time plocate serverConfig.html 
plocate serverConfig.html  0.01s user 0.01s system 93% cpu 0.017 total
1 Like

Good choice. Remember plocate also needs start&enable updatedb timer:

sudo systemctl enable plocate-updatedb.timer

sudo systemctl start plocate-updatedb.timer

This should be sufficient (it should ask for root as needed in the GUI) :wink:

systemctl enable --now plocate-updatedb.timer