You are not logged in.
since the update of systemd ( 223-1 ) I notice this error message on boot :
Failed to start Daily locate database update
How can I fix it ?
thanks
Offline
Since you provided no information about the error, I'm guessing it comes from updatedb.timer which is provided by mlocate. So please, post the full ouput of
systemctl status -l updatedb.timer
systemctl status -l updatedb.service
Offline
here is the result :
$ systemctl status -l updatedb.timer
● updatedb.timer - Daily locate database update
Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static; vendor preset: disabled)
Active: inactive (dead)
$ systemctl status -l updatedb.service
● updatedb.service
Loaded: masked (/dev/null)
Active: inactive (dead)
Warning: updatedb.service changed on disk. Run 'systemctl daemon-reload' to reload units.
I tried "systemctl disable updatedb.timer" but the error message is still here,
what I am sure is that the error message occurs only with systemd-223-1, with systemd-222 I don't have this problem
Last edited by Potomac (2015-07-31 13:35:33)
Offline
I find a workaround by masking the updatedb.timer :
systemctl mask updatedb.timer
I don't use updatedb timer, in systemd 222 it was masked/disabled, but for an unknown reason this timer is unmasked after the update of systemd to the 223 version
Last edited by Potomac (2015-07-31 14:06:42)
Offline
I don't use updatedb timer, in systemd 222 it was masked/disabled, but for an unknown reason this timer is unmasked after the update of systemd to the 223 version
TL;DR : upstream doesn't want you to disable it permanently
Services without a certain section (i THINK it's [install] but am not sure) can't be enabled or disabled .
Those services are activated in a different way.
The creator of the updatedb.service designed it to be run always.
Masking such a service is intended to be temporarily only, and it will be unmasked on next upgrade of systemd.
You have some options :
- redo the mask after every update of systemd
- write your own updatedb.service file WITH the needed section to use enable/disable and place it in /etc/systemd/check-documentation-where-to-put-it
Your custom service will now have precedence over the upstream-provided service file.
This does have the disadvantage that you have to keep track of changes to the service file done by upstream yourself.
- switch to an init system that allows changing such settings permanently
I was wrong about masks being overwritten on updates, masking should work and be permanent for any service.
Keep in mind though that on demand activation (ex: dbus-activated avahi service) may start masked services.
Last edited by Lone_Wolf (2020-01-02 15:37:59)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
thanks for your answer
Offline