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.
Thanks, though I was asking about updatedb.timer 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?
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…
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 systemdtimer, i.e. it runs only once a day, be it at midnight or, if the machine is down at midnight, upon the next boot.
“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
units).
This means they are not meant to be enabled using systemctl.
...etc...
See the hint from systemd i mentioned above
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:
Which means the developer choose to install the timer manually as a vendor. (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:
[Install]
WantedBy=multi-user.target
Followed by:
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)
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 “timers.target” instead of the “multi-user.target”. 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.
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 WantedBy=timers.target in the timer unit’s [Install] section.
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.
No i don’t have it installed, i just checked the file listing of the package via the GUI.
And just trying to help him with my knowledge of systemd so far
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/timers.target.wants/updatedb.timer
...
-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.
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
/mnt/sdb1/home/george/Downloads/config1/doc/_build/html/_modules/serverConfig.html
/mnt/sdb1/home/george.fedora/Downloads/config1/doc/_build/html/_modules/serverConfig.html
/mnt/sdb1/local/src/awips2-ade-20.3.2-20220531/awips/com.raytheon.viz.gfe/help/serverConfig.html
/mnt/sdb1/local/src/awips2_repos/AWIPS2_Dev_Baseline/cave/com.raytheon.viz.gfe/help/serverConfig.html
plocate serverConfig.html 0.01s user 0.01s system 93% cpu 0.017 total
Anyway, I started the service:
(That symbolic link is missing from the regular 
